On Jul 30, 2014, at 9:07 PM, Jim Thompson <[email protected]> wrote:

> 
>> On Jul 30, 2014, at 7:20 PM, Paul Mather <[email protected]> wrote:
>> 
>> Despite all that FreeBSD ZFS love, I still would not recommend it on
>> FreeBSD/i386-based installations (as the OP said he was using).  It is
>> much more of a headache to use in that milieu, and, IMHO, doesn't get
>> the testing and general care and feeding that the FreeBSD/amd64 version
>> gets.
> 
> Note that I said any use we make would be amd64 only.

That's a sane decision.

> 
>> Also, ZFS would not be a good fit on low-memory embedded hardware.
>> There are enough problems getting ARC to play nicely on high-memory
>> systems under memory pressure... :-)
> 
> What do you consider ‘low-memory’?

I'm thinking of these 256 MB and 512 MB ALIX-style systems people have 
been talking about on here as of late.  As you say, though, these are 
getting harder to obtain (as the designs are being phased out) as 4 GB 
RAM seems to be a de facto minimum nowadays.

I'm also thinking of "old junker" hardware that people at home might 
want to cobble together to protect their cable modem traffic.  Maybe I 
just hold onto hardware too long, but most of what I have available for 
that at home is i386-vintage with < 2 GB RAM. :-)

> It’s getting difficult to put less than 4GB in some systems.  ZFS works 
> really well on a 4GB system with around 100GB of ssd/m-sata.

I agree.  ZFS does work really well on a 4 GB FreeBSD/amd64 system.  
I've not put a pool on an SSD/m-SATA, so I can't speak to the lifespan 
of such a setup.  (The closest I've come is setting up a FreeNAS system 
at $WORK that has FreeNAS on a 32 GB SATA DOM; L2ARC on a 128 GB SSD; 
and the main data pool on 12 x 3 TB SATA hard drives.  FreeNAS mounts 
most everything, OS-wise, read-only, and tries to store configuration 
data on the data pool.  It's a good setup because it makes the FreeNAS 
software itself a FRU that's easily replaced should the disk it's on 
die.)

> auto-tuned ARC maximum is physical RAM less 1GB, or 1/2 of available RAM.  on 
> a 2GB system, this is 1GB, on a 4GB system, its 2GB.
> Have you looked at memory usage in pfSense lately?

Not really; mine is not heavily used in the grand scheme of things and 
so has lots of free RAM.  I don't use any add-on packages, though, that 
could compete in that arena.

It's nice to see RAM being appreciated, though.  When I bought a 
Netgate FW-7541 for $WORK it shipped with the i386 version of pfSense.  
I asked them nicely if I could please have an amd64 version so I could 
actually use all of the 4 GB of RAM and they kindly obliged.  
Hopefully, they are shipping amd64 versions as standard now on 64-bit 
capable 4+ GB RAM systems. ;-)

> Most of the ‘tuning guides’ consider fileserver/webserver/db applications.   
> pfSense is none of these.  There are several applications that would
> like to reliably write logfiles / rrd files, etc., however.

I agree about standard tuning guides, but also, with pfSense, I'd be 
concerned with the responsiveness of ARC to severe memory pressure.  
There have been many improvements in this area, but problems still 
remain (as I understand it) and ARC can still be sluggish and reluctant 
to allow the system to reclaim memory from ARC.  ARC memory is wired 
memory, and so it is competing with MBUFs and pf, both of which use 
kernel memory.  ARC responsiveness is one of the reasons why people 
still don't recommend to put swap on ZFS, or at least didn't the last 
time I looked.  The last thing you'd want is a spike in traffic to be 
stymied by ARC not getting out of the way quickly enough.  Unlike UFS, 
ZFS is not as intimately integrated into the VM subsystem and so is not 
as well orchestrated in the memory dance.

In the ~7 years I've used ZFS on FreeBSD I've lost ZFS pools twice.  
Admittedly, that was before the deep rollback functionality became 
available for pool imports, or even before zdb got how it is today.  It 
is HIGHLY reliable, IMHO, but, on the other hand, it isn't bulletproof. 
:-)

I do applaud the news that the developers are looking at ways to 
leverage ZFS to improve update and rollback.  That's one of the areas 
of ZFS I've greatly appreciated at $WORK, using beadm to create 
rollback checkpoints.  ZFS also takes Jail admin to another level!

Cheers,

Paul.
_______________________________________________
List mailing list
[email protected]
https://lists.pfsense.org/mailman/listinfo/list

Reply via email to