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

ZFS Parameters

2.1 Snapshot Feedback and Problems - RETIRED
6
8
3.4k
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 Jul 15, 2013, 3:50 PM

    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
    • J
      jimp Rebel Alliance Developer Netgate
      last edited by Jul 15, 2013, 4:23 PM

      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 Jul 17, 2013, 7:38 AM

        @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 Jul 17, 2013, 1:29 PM

          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 Jul 17, 2013, 9:15 PM

            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 Jul 17, 2013, 10:08 PM

              @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 Jul 17, 2013, 10:24 PM

                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 Aug 18, 2013, 3:20 AM Aug 17, 2013, 10:33 PM

                  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.