FreeBSD 9.0
-
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… :)
-
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.
-
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 amd64From 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?
-
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.
-
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.
-
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.
-
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?
-
Many.
http://doc.pfsense.org/index.php/Why_did_you_choose_FreeBSD_instead_of_%27insert_OS_here%27%3F
-
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.
-
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.
