Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    ZFS Parameters

    Scheduled Pinned Locked Moved 2.1 Snapshot Feedback and Problems - RETIRED
    8 Posts 6 Posters 3.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      jimdg
      last edited by

      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

      vm.kmem_size="512MB"
      vm.kmem_size_max="524MB"

      and I am still getting the message.

      Thanks for any help provided/

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        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.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • Z
          zenny
          last edited by

          @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.

          1 Reply Last reply Reply Quote 0
          • K
            Klaws
            last edited by

            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. ;-)

            1 Reply Last reply Reply Quote 0
            • Z
              zenny
              last edited by

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

              1 Reply Last reply Reply Quote 0
              • W
                wallabybob
                last edited by

                @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.

                1 Reply Last reply Reply Quote 0
                • Z
                  zenny
                  last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • N
                    NOYB
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.