1.\" Copyright (c) 2001 Matthew Dillon. Terms and conditions are those of 2.\" the BSD Copyright as specified in the file "/usr/src/COPYRIGHT" in 3.\" the source tree. 4.\" 5.Dd June 12, 2016 6.Dt TUNING 7 7.Os 8.Sh NAME 9.Nm tuning 10.Nd performance tuning under DragonFly 11.Sh SYSTEM SETUP 12Modern 13.Dx 14systems typically have just three partitions on the main drive. 15In order, a UFS 16.Pa /boot , 17.Pa swap , 18and a HAMMER 19.Pa root . 20The installer used to create separate PFSs for half a dozen directories, 21but now it just puts (almost) everything in the root. 22It will separate stuff that doesn't need to be backed up into a /build 23subdirectory and create null-mounts for things like /usr/obj, but it 24no longer creates separate PFSs for these. 25If desired, you can make /build its own mount to separate-out the 26components of the filesystem which do not need to be persistent. 27.Pp 28Generally speaking the 29.Pa /boot 30partition should be 1GB in size. This is the minimum recommended 31size, giving you room for backup kernels and alternative boot schemes. 32.Dx 33always installs debug-enabled kernels and modules and these can take 34up quite a bit of disk space (but will not take up any extra ram). 35.Pp 36In the old days we recommended that swap be sized to at least 2x main 37memory. These days swap is often used for other activities, including 38.Xr tmpfs 5 39and 40.Xr swapcache 8 . 41We recommend that swap be sized to the larger of 2x main memory or 421GB if you have a fairly small disk and 16GB or more if you have a 43modestly endowed system. 44If you have a modest SSD + large HDD combination, we recommend 45a large dedicated swap partition on the SSD. For example, if 46you have a 128GB SSD and 2TB or more of HDD storage, dedicating 47upwards of 64GB of the SSD to swap and using 48.Xr swapcache 8 49and 50.Xr tmpfs 5 51will significantly improve your HDD's performance. 52.Pp 53In an all-SSD or mostly-SSD system, 54.Xr swapcache 8 55is not normally used but you may still want to have a large swap 56partition to support 57.Xr tmpfs 5 58use. 59Our synth/poudriere build machines run with a 200GB 60swap partition and use tmpfs for all the builder jails. 50-100 GB 61is swapped out at the peak of the build. As a result, actual 62system storage bandwidth is minimized and performance increased. 63.Pp 64If you are on a minimally configured machine you may, of course, 65configure far less swap or no swap at all but we recommend at least 66some swap. 67The kernel's VM paging algorithms are tuned to perform best when there is 68swap space configured. 69Configuring too little swap can lead to inefficiencies in the VM 70page scanning code as well as create issues later on if you add 71more memory to your machine, so don't be shy about it. 72Swap is a good idea even if you don't think you will ever need it as it 73allows the 74machine to page out completely unused data and idle programs (like getty), 75maximizing the ram available for your activities. 76.Pp 77If you intend to use the 78.Xr swapcache 8 79facility with a SSD + HDD combination we recommend configuring as much 80swap space as you can on the SSD. 81However, keep in mind that each 1GByte of swapcache requires around 821MByte of ram, so don't scale your swap beyond the equivalent ram 83that you reasonably want to eat to support it. 84.Pp 85Finally, on larger systems with multiple drives, if the use 86of SSD swap is not in the cards or if it is and you need higher-than-normal 87swapcache bandwidth, you can configure swap on up to four drives and 88the kernel will interleave the storage. 89The swap partitions on the drives should be approximately the same size. 90The kernel can handle arbitrary sizes but 91internal data structures scale to 4 times the largest swap partition. 92Keeping 93the swap partitions near the same size will allow the kernel to optimally 94stripe swap space across the N disks. 95Do not worry about overdoing it a 96little, swap space is the saving grace of 97.Ux 98and even if you do not normally use much swap, it can give you more time to 99recover from a runaway program before being forced to reboot. 100However, keep in mind that any sort of swap space failure can lock the 101system up. 102Most machines are setup with only one or two swap partitions. 103.Pp 104Most 105.Dx 106systems have a single HAMMER root. 107PFSs can be used to administratively separate domains for backup purposes 108but tend to be a hassle otherwise so if you don't need the administrative 109separation you don't really need to use multiple HAMMER PFSs. 110All the PFSs share the same allocation layer so there is no longer a need 111to size each individual mount. 112Instead you should review the 113.Xr hammer 8 114manual page and use the 'hammer viconfig' facility to adjust snapshot 115retention and other parameters. 116By default 117HAMMER keeps 60 days worth of snapshots. 118Usually snapshots are not desired on PFSs such as 119.Pa /usr/obj 120or 121.Pa /tmp 122since data on these partitions cycles a lot. 123.Pp 124If a very large work area is desired it is often beneficial to 125configure it as a separate HAMMER mount. If it is integrated into 126the root mount it should at least be its own HAMMER PFS. 127We recommend naming the large work area 128.Pa /build . 129Similarly if a machine is going to have a large number of users 130you might want to separate your 131.Pa /home 132out as well. 133.Pp 134A number of run-time 135.Xr mount 8 136options exist that can help you tune the system. 137The most obvious and most dangerous one is 138.Cm async . 139Do not ever use it; it is far too dangerous. 140A less dangerous and more 141useful 142.Xr mount 8 143option is called 144.Cm noatime . 145.Ux 146filesystems normally update the last-accessed time of a file or 147directory whenever it is accessed. 148However, this creates a massive burden on copy-on-write filesystems like 149HAMMER, particularly when scanning the filesystem. 150.Dx 151currently defaults to disabling atime updates on HAMMER mounts. 152It can be enabled by setting the 153.Va vfs.hammer.noatime 154tunable to 0 in 155.Xr loader.conf 5 156but we recommend leaving it disabled. 157The lack of atime updates can create issues with certain programs 158such as when detecting whether unread mail is present, but 159applications for the most part no longer depend on it. 160.Sh SSD SWAP 161The single most important thing you can do is have at least one 162solid-state drive in your system, and configure your swap space 163on that drive. 164If you are using a combination of a smaller SSD and a very larger HDD, 165you can use 166.Xr swapcache 8 167to automatically cache data from your HDD. 168But even if you do not, having swap space configured on your SSD will 169significantly improve performance under even modest paging loads. 170It is particularly useful to configure a significant amount of swap 171on a workstation, 32GB or more is not uncommon, to handle bloated 172leaky applications such as browsers. 173.Sh SYSCTL TUNING 174.Xr sysctl 8 175variables permit system behavior to be monitored and controlled at 176run-time. 177Some sysctls simply report on the behavior of the system; others allow 178the system behavior to be modified; 179some may be set at boot time using 180.Xr rc.conf 5 , 181but most will be set via 182.Xr sysctl.conf 5 . 183There are several hundred sysctls in the system, including many that appear 184to be candidates for tuning but actually are not. 185In this document we will only cover the ones that have the greatest effect 186on the system. 187.Pp 188The 189.Va kern.ipc.shm_use_phys 190sysctl defaults to 1 (on) and may be set to 0 (off) or 1 (on). 191Setting 192this parameter to 1 will cause all System V shared memory segments to be 193mapped to unpageable physical RAM. 194This feature only has an effect if you 195are either (A) mapping small amounts of shared memory across many (hundreds) 196of processes, or (B) mapping large amounts of shared memory across any 197number of processes. 198This feature allows the kernel to remove a great deal 199of internal memory management page-tracking overhead at the cost of wiring 200the shared memory into core, making it unswappable. 201.Pp 202The 203.Va vfs.write_behind 204sysctl defaults to 1 (on). This tells the filesystem to issue media 205writes as full clusters are collected, which typically occurs when writing 206large sequential files. The idea is to avoid saturating the buffer 207cache with dirty buffers when it would not benefit I/O performance. However, 208this may stall processes and under certain circumstances you may wish to turn 209it off. 210.Pp 211The 212.Va vfs.hirunningspace 213sysctl determines how much outstanding write I/O may be queued to 214disk controllers system wide at any given instance. The default is 215usually sufficient but on machines with lots of disks you may want to bump 216it up to four or five megabytes. Note that setting too high a value 217(exceeding the buffer cache's write threshold) can lead to extremely 218bad clustering performance. Do not set this value arbitrarily high! Also, 219higher write queueing values may add latency to reads occurring at the same 220time. 221The 222.Va vfs.bufcache_bw 223controls data cycling within the buffer cache. I/O bandwidth less than 224this specification (per second) will cycle into the much larger general 225VM page cache while I/O bandwidth in excess of this specification will 226be recycled within the buffer cache, reducing the load on the rest of 227the VM system. 228The default value is 200 megabytes (209715200), which means that the 229system will try harder to cache data coming off a slower hard drive 230and less hard trying to cache data coming off a fast SSD. 231This parameter is particularly important if you have NVMe drives in 232your system as these storage devices are capable of transferring 233well over 2GBytes/sec into the system. 234.Pp 235There are various other buffer-cache and VM page cache related sysctls. 236We do not recommend modifying their values. 237As of 238.Fx 4.3 , 239the VM system does an extremely good job tuning itself. 240.Pp 241The 242.Va net.inet.tcp.sendspace 243and 244.Va net.inet.tcp.recvspace 245sysctls are of particular interest if you are running network intensive 246applications. 247They control the amount of send and receive buffer space 248allowed for any given TCP connection. 249However, 250.Dx 251now auto-tunes these parameters using a number of other related 252sysctls (run 'sysctl net.inet.tcp' to get a list) and usually 253no longer need to be tuned manually. 254We do not recommend 255increasing or decreasing the defaults if you are managing a very large 256number of connections. 257Note that the routing table (see 258.Xr route 8 ) 259can be used to introduce route-specific send and receive buffer size 260defaults. 261.Pp 262As an additional management tool you can use pipes in your 263firewall rules (see 264.Xr ipfw 8 ) 265to limit the bandwidth going to or from particular IP blocks or ports. 266For example, if you have a T1 you might want to limit your web traffic 267to 70% of the T1's bandwidth in order to leave the remainder available 268for mail and interactive use. 269Normally a heavily loaded web server 270will not introduce significant latencies into other services even if 271the network link is maxed out, but enforcing a limit can smooth things 272out and lead to longer term stability. 273Many people also enforce artificial 274bandwidth limitations in order to ensure that they are not charged for 275using too much bandwidth. 276.Pp 277Setting the send or receive TCP buffer to values larger than 65535 will result 278in a marginal performance improvement unless both hosts support the window 279scaling extension of the TCP protocol, which is controlled by the 280.Va net.inet.tcp.rfc1323 281sysctl. 282These extensions should be enabled and the TCP buffer size should be set 283to a value larger than 65536 in order to obtain good performance from 284certain types of network links; specifically, gigabit WAN links and 285high-latency satellite links. 286RFC 1323 support is enabled by default. 287.Pp 288The 289.Va net.inet.tcp.always_keepalive 290sysctl determines whether or not the TCP implementation should attempt 291to detect dead TCP connections by intermittently delivering 292.Dq keepalives 293on the connection. 294By default, this is now enabled for all applications. 295We do not recommend turning it off. 296The extra network bandwidth is minimal and this feature will clean-up 297stalled and long-dead connections that might not otherwise be cleaned 298up. 299In the past people using dialup connections often did not want to 300use this feature in order to be able to retain connections across 301long disconnections, but in modern day the only default that makes 302sense is for the feature to be turned on. 303.Pp 304The 305.Va net.inet.tcp.delayed_ack 306TCP feature is largely misunderstood. Historically speaking this feature 307was designed to allow the acknowledgement to transmitted data to be returned 308along with the response. For example, when you type over a remote shell 309the acknowledgement to the character you send can be returned along with the 310data representing the echo of the character. With delayed acks turned off 311the acknowledgement may be sent in its own packet before the remote service 312has a chance to echo the data it just received. This same concept also 313applies to any interactive protocol (e.g. SMTP, WWW, POP3) and can cut the 314number of tiny packets flowing across the network in half. The 315.Dx 316delayed-ack implementation also follows the TCP protocol rule that 317at least every other packet be acknowledged even if the standard 100ms 318timeout has not yet passed. Normally the worst a delayed ack can do is 319slightly delay the teardown of a connection, or slightly delay the ramp-up 320of a slow-start TCP connection. While we aren't sure we believe that 321the several FAQs related to packages such as SAMBA and SQUID which advise 322turning off delayed acks may be referring to the slow-start issue. 323.Pp 324The 325.Va net.inet.tcp.inflight_enable 326sysctl turns on bandwidth delay product limiting for all TCP connections. 327This feature is now turned on by default and we recommend that it be 328left on. 329It will slightly reduce the maximum bandwidth of a connection but the 330benefits of the feature in reducing packet backlogs at router constriction 331points are enormous. 332These benefits make it a whole lot easier for router algorithms to manage 333QOS for multiple connections. 334The limiting feature reduces the amount of data built up in intermediate 335router and switch packet queues as well as reduces the amount of data built 336up in the local host's interface queue. With fewer packets queued up, 337interactive connections, especially over slow modems, will also be able 338to operate with lower round trip times. However, note that this feature 339only affects data transmission (uploading / server-side). It does not 340affect data reception (downloading). 341.Pp 342The system will attempt to calculate the bandwidth delay product for each 343connection and limit the amount of data queued to the network to just the 344amount required to maintain optimum throughput. This feature is useful 345if you are serving data over modems, GigE, or high speed WAN links (or 346any other link with a high bandwidth*delay product), especially if you are 347also using window scaling or have configured a large send window. 348.Pp 349For production use setting 350.Va net.inet.tcp.inflight_min 351to at least 6144 may be beneficial. Note, however, that setting high 352minimums may effectively disable bandwidth limiting depending on the link. 353.Pp 354Adjusting 355.Va net.inet.tcp.inflight_stab 356is not recommended. 357This parameter defaults to 50, representing +5% fudge when calculating the 358bwnd from the bw. This fudge is on top of an additional fixed +2*maxseg 359added to bwnd. The fudge factor is required to stabilize the algorithm 360at very high speeds while the fixed 2*maxseg stabilizes the algorithm at 361low speeds. If you increase this value excessive packet buffering may occur. 362.Pp 363The 364.Va net.inet.ip.portrange.* 365sysctls control the port number ranges automatically bound to TCP and UDP 366sockets. There are three ranges: A low range, a default range, and a 367high range, selectable via an IP_PORTRANGE 368.Fn setsockopt 369call. 370Most network programs use the default range which is controlled by 371.Va net.inet.ip.portrange.first 372and 373.Va net.inet.ip.portrange.last , 374which defaults to 1024 and 5000 respectively. Bound port ranges are 375used for outgoing connections and it is possible to run the system out 376of ports under certain circumstances. This most commonly occurs when you are 377running a heavily loaded web proxy. The port range is not an issue 378when running serves which handle mainly incoming connections such as a 379normal web server, or has a limited number of outgoing connections such 380as a mail relay. For situations where you may run yourself out of 381ports we recommend increasing 382.Va net.inet.ip.portrange.last 383modestly. A value of 10000 or 20000 or 30000 may be reasonable. You should 384also consider firewall effects when changing the port range. Some firewalls 385may block large ranges of ports (usually low-numbered ports) and expect systems 386to use higher ranges of ports for outgoing connections. For this reason 387we do not recommend that 388.Va net.inet.ip.portrange.first 389be lowered. 390.Pp 391The 392.Va kern.ipc.somaxconn 393sysctl limits the size of the listen queue for accepting new TCP connections. 394The default value of 128 is typically too low for robust handling of new 395connections in a heavily loaded web server environment. 396For such environments, 397we recommend increasing this value to 1024 or higher. 398The service daemon 399may itself limit the listen queue size (e.g.\& 400.Xr sendmail 8 , 401apache) but will 402often have a directive in its configuration file to adjust the queue size up. 403Larger listen queues also do a better job of fending off denial of service 404attacks. 405.Pp 406The 407.Va kern.maxvnodes 408specifies how many vnodes and related file structures the kernel will 409cache. 410The kernel uses a very generous default for this parameter based on 411available physical memory. 412You generally do not want to mess with this parameter as it directly 413effects how well the kernel can cache not only file structures but also 414the underlying file data. 415But you can lower it if kernel memory use is higher than you would like. 416.Pp 417The 418.Va kern.maxfiles 419sysctl determines how many open files the system supports. 420The default is 421typically based on available physical memory but you may need to bump 422it up if you are running databases or large descriptor-heavy daemons. 423The read-only 424.Va kern.openfiles 425sysctl may be interrogated to determine the current number of open files 426on the system. 427.Pp 428The 429.Va vm.swap_idle_enabled 430sysctl is useful in large multi-user systems where you have lots of users 431entering and leaving the system and lots of idle processes. 432Such systems 433tend to generate a great deal of continuous pressure on free memory reserves. 434Turning this feature on and adjusting the swapout hysteresis (in idle 435seconds) via 436.Va vm.swap_idle_threshold1 437and 438.Va vm.swap_idle_threshold2 439allows you to depress the priority of pages associated with idle processes 440more quickly than the normal pageout algorithm. 441This gives a helping hand 442to the pageout daemon. 443Do not turn this option on unless you need it, 444because the tradeoff you are making is to essentially pre-page memory sooner 445rather than later, eating more swap and disk bandwidth. 446In a small system 447this option will have a detrimental effect but in a large system that is 448already doing moderate paging this option allows the VM system to stage 449whole processes into and out of memory more easily. 450.Sh LOADER TUNABLES 451Some aspects of the system behavior may not be tunable at runtime because 452memory allocations they perform must occur early in the boot process. 453To change loader tunables, you must set their values in 454.Xr loader.conf 5 455and reboot the system. 456.Pp 457.Va kern.maxusers 458controls the scaling of a number of static system tables, including defaults 459for the maximum number of open files, sizing of network memory resources, etc. 460On 461.Dx , 462.Va kern.maxusers 463is automatically sized at boot based on the amount of memory available in 464the system, and may be determined at run-time by inspecting the value of the 465read-only 466.Va kern.maxusers 467sysctl. 468Some sites will require larger or smaller values of 469.Va kern.maxusers 470and may set it as a loader tunable; values of 64, 128, and 256 are not 471uncommon. 472We do not recommend going above 256 unless you need a huge number 473of file descriptors; many of the tunable values set to their defaults by 474.Va kern.maxusers 475may be individually overridden at boot-time or run-time as described 476elsewhere in this document. 477.Pp 478.Va kern.nbuf 479sets how many filesystem buffers the kernel should cache. 480Filesystem buffers can be up to 128KB each. UFS typically uses an 8KB 481blocksize while HAMMER typically uses 64KB. 482The defaults usually suffice. 483The cached buffers represent wired physical memory so specifying a value 484that is too large can result in excessive kernel memory use, and is also 485not entirely necessary since the pages backing the buffers are also 486cached by the VM page cache (which does not use wired memory). 487The buffer cache significantly improves the hot path for cached file 488accesses. 489.Pp 490The 491.Va kern.dfldsiz 492and 493.Va kern.dflssiz 494tunables set the default soft limits for process data and stack size 495respectively. 496Processes may increase these up to the hard limits by calling 497.Xr setrlimit 2 . 498The 499.Va kern.maxdsiz , 500.Va kern.maxssiz , 501and 502.Va kern.maxtsiz 503tunables set the hard limits for process data, stack, and text size 504respectively; processes may not exceed these limits. 505The 506.Va kern.sgrowsiz 507tunable controls how much the stack segment will grow when a process 508needs to allocate more stack. 509.Pp 510.Va kern.ipc.nmbclusters 511and 512.Va kern.ipc.nmbjclusters 513may be adjusted to increase the number of network mbufs the system is 514willing to allocate. 515Each normal cluster represents approximately 2K of memory, 516so a value of 1024 represents 2M of kernel memory reserved for network 517buffers. 518Each 'j' cluster is typically 4KB, so a value of 1024 represents 4M of 519kernel memory. 520You can do a simple calculation to figure out how many you need but 521keep in mind that tcp buffer sizing is now more dynamic than it used to 522be. 523.Pp 524The defaults usually suffice but you may want to bump it up on service-heavy 525machines. 526Modern machines often need a large number of mbufs to operate services 527efficiently, values of 65536, even upwards of 262144 or more are common. 528If you are running a server, it is better to be generous than to be frugal. 529Remember the memory calculation though. 530.Pp 531Under no circumstances 532should you specify an arbitrarily high value for this parameter, it could 533lead to a boot-time crash. 534The 535.Fl m 536option to 537.Xr netstat 1 538may be used to observe network cluster use. 539.Sh KERNEL CONFIG TUNING 540There are a number of kernel options that you may have to fiddle with in 541a large-scale system. 542In order to change these options you need to be 543able to compile a new kernel from source. 544The 545.Xr config 8 546manual page and the handbook are good starting points for learning how to 547do this. 548Generally the first thing you do when creating your own custom 549kernel is to strip out all the drivers and services you do not use. 550Removing things like 551.Dv INET6 552and drivers you do not have will reduce the size of your kernel, sometimes 553by a megabyte or more, leaving more memory available for applications. 554.Pp 555If your motherboard is AHCI-capable then we strongly recommend turning 556on AHCI mode in the BIOS if it is not the default. 557.Sh CPU, MEMORY, DISK, NETWORK 558The type of tuning you do depends heavily on where your system begins to 559bottleneck as load increases. 560If your system runs out of CPU (idle times 561are perpetually 0%) then you need to consider upgrading the CPU or moving to 562an SMP motherboard (multiple CPU's), or perhaps you need to revisit the 563programs that are causing the load and try to optimize them. 564If your system 565is paging to swap a lot you need to consider adding more memory. 566If your 567system is saturating the disk you typically see high CPU idle times and 568total disk saturation. 569.Xr systat 1 570can be used to monitor this. 571There are many solutions to saturated disks: 572increasing memory for caching, mirroring disks, distributing operations across 573several machines, and so forth. 574.Pp 575Finally, you might run out of network suds. 576Optimize the network path 577as much as possible. 578If you are operating a machine as a router you may need to 579setup a 580.Xr pf 4 581firewall (also see 582.Xr firewall 7 . 583.Dx 584has a very good fair-share queueing algorithm for QOS in 585.Xr pf 4 . 586.Sh SOURCE OF KERNEL MEMORY USAGE 587The primary sources of kernel memory usage are: 588.Bl -tag -width ".Va kern.maxvnodes" 589.It Va kern.maxvnodes 590The maximum number of cached vnodes in the system. 591These can eat quite a bit of kernel memory, primarily due to auxiliary 592structures tracked by the HAMMER filesystem. 593It is relatively easy to configure a smaller value, but we do not 594recommend reducing this parameter below 100000. 595Smaller values directly impact the number of discrete files the 596kernel can cache data for at once. 597.It Va kern.ipc.nmbclusters , Va kern.ipc.nmbjclusters 598Calculate approximately 2KB per normal cluster and 4KB per jumbo 599cluster. 600Do not make these values too low or you risk deadlocking the network 601stack. 602.It Va kern.nbuf 603The number of filesystem buffers managed by the kernel. 604The kernel wires the underlying cached VM pages, typically 8KB (UFS) or 60564KB (HAMMER) per buffer. 606.It swap/swapcache 607Swap memory requires approximately 1MB of physical ram for each 1GB 608of swap space. 609When swapcache is used, additional memory may be required to keep 610VM objects around longer (only really reducable by reducing the 611value of 612.Va kern.maxvnodes 613which you can do post-boot if you desire). 614.It tmpfs 615Tmpfs is very useful but keep in mind that while the file data itself 616is backed by swap, the meta-data (the directory topology) requires 617wired kernel memory. 618.It mmu page tables 619Even though the underlying data pages themselves can be paged to swap, 620the page tables are usually wired into memory. 621This can create problems when a large number of processes are mmap()ing 622very large files. 623Sometimes turning on 624.Va machdep.pmap_mmu_optimize 625suffices to reduce overhead. 626Page table kernel memory use can be observed by using 'vmstat -z' 627.It Va kern.ipc.shm_use_phys 628It is sometimes necessary to force shared memory to use physical memory 629when running a large database which uses shared memory to implement its 630own data caching. 631The use of sysv shared memory in this regard allows the database to 632distinguish between data which it knows it can access instantly (i.e. 633without even having to page-in from swap) verses data which it might require 634and I/O to fetch. 635.Pp 636If you use this feature be very careful with regards to the database's 637shared memory configuration as you will be wiring the memory. 638.El 639.Sh SEE ALSO 640.Xr netstat 1 , 641.Xr systat 1 , 642.Xr dm 4 , 643.Xr dummynet 4 , 644.Xr nata 4 , 645.Xr pf 4 , 646.Xr login.conf 5 , 647.Xr pf.conf 5 , 648.Xr rc.conf 5 , 649.Xr sysctl.conf 5 , 650.Xr firewall 7 , 651.Xr hier 7 , 652.Xr boot 8 , 653.Xr ccdconfig 8 , 654.Xr config 8 , 655.Xr disklabel 8 , 656.Xr fsck 8 , 657.Xr ifconfig 8 , 658.Xr ipfw 8 , 659.Xr loader 8 , 660.Xr mount 8 , 661.Xr newfs 8 , 662.Xr route 8 , 663.Xr sysctl 8 , 664.Xr tunefs 8 665.Sh HISTORY 666The 667.Nm 668manual page was originally written by 669.An Matthew Dillon 670and first appeared 671in 672.Fx 4.3 , 673May 2001. 674