ZFS Parameters

  • During my startup I noticed the following messages and I am having issues with lockups

    ZFS NOTICE: Prefetch is disabled by default on i386 – to enable,
                add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf.
    ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior.
                Consider tuning vm.kmem_size and vm.kmem_size_max
                in /boot/loader.conf.

    Would this have anything to do with the lockups?

    I went ahead and modified loader.conf to the following


    and I am still getting the message.

    Thanks for any help provided/

  • Rebel Alliance Developer Netgate

    We don't use zfs by default so the messages are irrelevant.

    If you're seeing crashes/hangs, update to a current snapshot. Some FTP patches that caused crashes and hangs were backed out on Sunday so current snapshots should be OK.

  • @jimp: I upgraded to July 15 snapshot after I read your post above and the notification (harmless) still persists.

    However, I am thinking of using zfs to mount /usr, /usr/local, /var (though it is md device) in a zpool to quicken the upgrade process which otherwise takes hours to take place, fyi.

  • The firmware upgrade process (via the WebGUI) should take a few minutes, not a few hours - assuming an average installation.

    If you chose to perform a "full backup" during the firmware upgrade, it might be thata severly underpowered CPU can be the bottleneck (AFAIR, the backup image gets GZIPped).

    Another "nice surprise" can come from the use of USB memory sticks. I was once getting abysmal I/O performance on a thin client. Took e a few days to discover that the USB drive was running at USB 1.1 speed. Well, rather USB 1.1 lack-of-speed. ;-)

  • pfSense NanoBSD upgrade through webGUI is taking hours in my case with USB 2 and USB 3 (both usb ports and sticks), fyi.

  • @zenny:

    pfSense NanoBSD upgrade through webGUI is taking hours in my case with USB 2 and USB 3 (both usb ports and sticks), fyi.

    How many "hours"? 0.1? 0.5? 2? …

    A few years back it seemed to me that automatic upgrades were taking a "long" time. Investigation suggested the downloads were running slowly and were "fragile" (would sometimes appear to stall for "long" periods). I decided to download the upgrade files through a web browser and then upload them to the pfSense box. That seemed to work much better and works "well enough" that I haven't changed from that practice.

    I use a solid state DOM as my hard drive. dd can do raw writes to it at about 9MB/sec (not very speedy). I would guess a firmware upgrade takes of the order of 0.16 to 0.25 hours from start of upload to reboot. I am running "full" version. not nanoBSD.

  • Usually takes some 2.5+ hours to upgrade the snapshots from GUI.

    Yes, like you stated, mounting a HDD/SDD and download the upgrade img to the HDD and then manaully upgrade using the file from console is what I have been thinking.

  • I've been running full install on 4gb usb 2.0 flash stick for nearly a year and have never even approached 30 minutes for an upgrade.

    I typically do console upgrade so can better see progression.  Download is usually a couple minutes.  Then the upgrade is about 9 minutes (~7 rows of dots).  Then the reboot and packages reinstall is maybe another 5 minutes.

    To ensure the best USB flash performance use devices that are rated for ReadyBoost.

    I did install once on a non ReadyBoost device and it was agonizingly slow.

Log in to reply