FreeBSD 9.0



  • I was wondering if there are any plans on using the FreeBSD 9.0 kernel, and moving away from 8.3?



  • FreeBSD 9.0 was intended for pfsense 2.1 but the developers say that there are so many things to change and some parts are unstable and so it will be just FreeBSD 8.3 for pfsense 2.1.

    Later versions will probably have FreeBSD 9.0



  • It's planned for 2.2 currently



  • Sweet.  Thanks so much for your amazing help and work on the project!



  • Considering one of pfsense's main building blocks is pf, isn't it a bit disheartening that FreeBSD's pf is so far behind the latest version?

    Right now FreeBSD 8.3 includes pf 4.1, which was released 5 years ago.

    Even the general-purpose Mac OS X Lion (OS X 10.7) includes a newer version (pf 4.3).

    Meanwhile OpenBSD will be releasing 5.1 in about a month: http://www.openbsd.org/51.html



  • Our pf isn't really the same as the one freebsd ships with. There are a number of extension specific to our project.

    That said, the big change configuration file is a significant undertaking to get right.



  • @databeestje:

    Our pf isn't really the same as the one freebsd ships with. There are a number of extension specific to our project.

    Are those pf extensions the ones listed at
    https://github.com/bsdperimeter/pfsense-tools/tree/master/patches/RELENG_8_3
    or are there more ?

    TIA



  • those are it, some are shaper related or for layer 7 filtering, which isn't going to go into free or open anyhow.



  • now PF 2.1 version support SATA Disk ?

    I want to buy new server.



  • @yon:

    now PF 2.1 version support SATA Disk ?

    I want to buy new server.

    Pfsense has "supported" sata disks for many years. And its about the hdd controllers,not the hdd's or the bustype… :)



  • @dhatz:

    Considering one of pfsense's main building blocks is pf, isn't it a bit disheartening that FreeBSD's pf is so far behind the latest version?

    No, there isn't anything in newer versions we would benefit from that we don't already have back ported.



  • @cmb:

    No, there isn't anything in newer versions we would benefit from that we don't already have back ported.

    Can we take that as a confirmation that TRIM will be included then?



  • Considering the amount of disk space pfSense normally uses TRIM for SSDs is moot. With just writing to some RRD databases it's not going to make much difference, if at all.

    TRIM is something to maintain performance if you fill the disk and delete everything. Which isn't very likely.

    If it's in FreeBSD 8.3, great, otherwise I see no point in investing time to backport it.



  • TRIM makes a lot of sense in the context of certain packages, such as squid.



  • you do realize that squid, in combination with TRIM will wear your SSD out faster, right?



  • Yes, but in terms of performance that's the way to go.


  • Rebel Alliance Developer Netgate

    TRIM is in 8.3 already.

    [2.1-DEVELOPMENT][root@pfsense-amd64.localdomain]/root(2): tunefs --help
    usage: tunefs [-A] [-a enable | disable] [-e maxbpg] [-f avgfilesize]
                  [-J enable | disable ] [-L volname] [-l enable | disable]
                  [-m minfree] [-N enable | disable] [-n enable | disable]
                  [-o space | time] [-p] [-s avgfpdir] [-t enable | disable]
                  special | filesystem
    [2.1-DEVELOPMENT][root@pfsense-amd64.localdomain]/root(3): uname -a
    FreeBSD pfsense-amd64.localdomain 8.3-RC2 FreeBSD 8.3-RC2 #1: Fri Mar 23 11:17:24 EDT 2012     root@FreeBSD_8.3_pfSense_2.1.snaps.pfsense.org:/usr/obj./usr/pfSensesrc/src/sys/pfSense_SMP.8  amd64
    

    From tunefs(8)

    -t enable | disable
                Turn on/off the TRIM enable flag.  If enabled, and if the under-
                lying device supports the BIO_DELETE command, the file system
                will send a delete request to the underlying device for each
                freed block.  The trim enable flag is typically set when the
                underlying device uses flash-memory as the device can use the
                delete command to pre-zero or at least avoid copying blocks that
                have been deleted.

    Can't be set on a live FS, has to be done when booted/mounted from some other media (iso, memstick, attached to another 8.3 box, etc).



  • Good news, Jim. Could I request that it be an option in the installer then, and/or enabled by default for SSDs?


  • Rebel Alliance Developer Netgate

    Seeing as "detecting" an SSD would be non-trivial at that stage, probably an option might be helpful. Open a ticket at redmine (if there isn't one already). It may not make 2.1 unless someone gets time to add it (or funds it). Adding it to the experimental web-based installer (/installer/) would be much easier than adding it in the console/curses installer.



  • @jimp:

    Seeing as "detecting" an SSD would be non-trivial at that stage

    Are there ill effects of enabling TRIM on a non-SSD? Maybe SSD detection is moot, and the installer simply needs to choose a default and/or give the user a choice.

    I will open a ticket in redmine.


  • Rebel Alliance Developer Netgate

    Not sure, but when it comes to filesystems, I'd rather not play it fast and loose with options. Setting only what is necessary is best.



  • @dhatz:

    Meanwhile OpenBSD will be releasing 5.1 in about a month: http://www.openbsd.org/51.html

    meanwhile, was there any reasons why not simply run pfSense over OpenBSD instead of FreeBSD?  Is there things only found on FreeBSD that pfSense would absolutely requires?


  • Rebel Alliance Developer Netgate



  • Based on the status of each *BSD project 6+ years ago, I fully understand pfsense's choice to go with FreeBSD.

    However it seems that most of OpenBSD's new developments and innovations are focused on exactly the firewall/router "security-appliance" niche, so much so that FreeBSD developer Bjoern A. Zeeb wrote back in 2009: "OpenBSD seems to move further and further in the direction to be an operating system around pf, rather than pf being a firewall implementation for the OS".

    NetBSD is developing npf (check Introducing NPF, NetBSD's new packet filter) a MP scalable pf-like packet-filter.

    Whereas FreeBSD seems to be taking a more generic "server OS" path, adding great features like ZFS and VM, but staying behind on the pf packet filter front and other related functionality (note: although FreeBSD native packet-filter ipfw does offer proper NAT of PPTP and NAT before IPsec, which just about any Linux-based firewall offers).



  • that's nice, but i see a lot of movement of pfSense towards the general appliances too. Not that we strictly cater to one, but some have been combining duties.

    Things like proxies, and reverse proxies and load balancer tend to cut into the general server workload area. One can never win them all.

    It does probably have the larger userbase of the *BSDs which means it generally has decent hardware support.


  • Rebel Alliance Developer Netgate

    npf was still very much a dream last time I looked in on it, it was nowhere near capable enough (without commenting on the rest of NetBSD)… As for OpenBSD, I doubt that would ever happen.

    While they do have some nice routing improvements over Free, their attitude toward projects based off of OpenBSD has not been very welcoming.

    FreeBSD seems to still have the best possible combination of all factors involved. The others may edge it out in certain areas but they can't beat the total package.


Log in to reply