Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
No Starch Press

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents

· Introduction to Operating Systems
· Linux Basics
· Working with the System
· Shells and Utilities
· Editing Files
· Basic Administration
· The Operating System
· The X Windowing System
· The Computer Itself
· Networking
· System Monitoring
· Solving Problems
· Security
· Installing and Upgrading
· Linux and Windows

Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
Copyright Info
Terms of Use
Privacy Info
Masthead / Impressum
Your Account

Private Messages

News Archive
Submit News
User Articles
Web Links


The Web

Who's Online
There are currently, 73 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here




       nhfsstone  [ -v ] [[ -t secs ] | [ -c calls ]] [ -l load ]
       [ -p nprocs ] [ -m mixfile ] [ dir ]...


       nhfsstone (pronounced n-f-s-stone, the "h" is  silent)  is
       used on a NFS client to generate an artificial load with a
       particular mix of NFS operations. It reports  the  average
       response  time  of the server in milliseconds per call and
       the load in calls per second.   The  program  adjusts  its
       calling  patterns based on the client's kernel NFS statis­
       tics and the elapsed time.  Load can be generated  over  a
       given time or number of NFS calls.

       Because  it  uses the kernel NFS statistics to monitor its
       progress, nhfsstone cannot be used to measure the  perfor­
       mance of non-NFS filesystems.

       The nhfsstone program uses file and directory manipulation
       in an attempt to generate  particular  NFS  operations  in
       response  to  particular system calls.  To do this it uses
       several tricks that are based on a knowledge of the imple­
       mentation  of  the  NFS  client  side reference port.  For
       example, it uses long file names to circumvent the  kernel
       name  lookup cache so that a stat(2) system call generates
       an NFS lookup operation.

       The mix of NFS operations can be  set  with  a  mix  file,
       which  is  the  output of the nfsstat(8C) command (see the
       "-m" option below).  The percentages taken  from  the  mix
       file  are calculated based on the number of NFS calls, not
       on the percentages printed by nfsstat. Operations with  0%
       in  the mix will never get called by nhfsstone.  In a real
       server load mix, even though the percentage of call for  a
       particular  NFS operation may be zero, the number of calls
       is often nonzero.  Nhfsstone makes the assumption that the
       number of calls to these 0 percent operations will have an
       insignificant effect on server response.

       Normally nhfsstone should be given a list of two  or  more
       test  directories  to  use  (default is to use the current
       directory).  The test directories used should  be  located
       on different disks and partitions on the server to realis­
       tically simulate typical  server  loads.   Each  nhfsstone
       process  looks for a directory <dir>/testdir<n> (where <n>
       is a number from 0 to nprocs - 1).  If a process directory
       name  already exists, it is checked for the correct set of
       test files.  Otherwise the directory is created and  popu­


       -v          Verbose output.
                   or small amount  of  memory)  fewer  processes
                   might be used to avoid swapping.

       -m mixfile  Mix of NFS operations to generate.  The format
                   of mixfile is the same as the  output  of  the
                   nfsstat(8C)  program.   A mix file can be cre­
                   ated on a server by typing "nfsstat -s >  mix­
                   file".  The default mix of operations is: null
                   0%, getattr 13%, setattr 1%, root  0%,  lookup
                   34%,  readlink 8%, read 22%, wrcache 0%, write
                   15%, create 2%, remove 1%, rename 0%, link 0%,
                   symlink  0%,  mkdir  0%, rmdir 0%, readdir 3%,
                   fsstat 1%.


       As with all benchmarks, nhfsstone can only provide numbers
       that  are  useful  if  experiments  that use it are set up
       carefully.  Since it is measuring servers,  it  should  be
       run  on a client that will not limit the generation of NFS
       requests.  This means it should have a fast  CPU,  a  good
       ethernet  interface and the machine should not be used for
       anything else during testing.   A  Sun-3/50  can  generate
       about 60 NFS calls per second before it runs out of CPU.

       Nhfsstone  assumes  that  all  NFS  calls generated on the
       client are going to a single server, and that all  of  the
       NFS  load  on  that server is due to this client.  To make
       this assumption hold, both the client and server should be
       as quiescent as possible during tests.

       If  the network is heavily utilized the delays due to col­
       lisions may hide any changes in server performance.   High
       error  rates on either the client or server can also cause
       delays due to retransmissions of lost or damaged  packets.
       netstat(8C) -i can be used to measure the error and colli­
       sion rates on the client and server.

       To best simulate the effects of NFS clients on the server,
       the  test directories should be set up so that they are on
       at least two  of  the  disk  partitions  that  the  server
       exports  and the partitions should be as far apart as pos­
       sible. The dkinfo(8) command can be used to find the phys­
       ical  geometry  of  disk on BSD based systems.  NFS opera­
       tions tend to randomize access the whole disk  so  putting
       all  of  the nhfsstone test directories on a single parti­
       tion or on two partitions that are close together will not
       show realistic results.

       On all tests it is a good idea to run the tests repeatedly
       and compare results.  The number of calls can be increased
       (with  the  -c  option) until the variance in milliseconds
       per call is acceptably small.  If increasing the number of
       measured  response  time due to context switching or other
       delays on the client machine, while changing  the  mix  of
       NFS operations will change the whole nature of the experi­
       ment.  Other changes to the client configuration may  also
       effect  the  comparability  of  results.   While nhfsstone
       tries to compensate for differences in  client  configura­
       tions  by sampling the actual NFS statistics and adjusting
       both the load and mix of operations, some changes are  not
       reflected  in  either  the  load  or the mix. For example,
       installing a faster CPU or mounting different NFS filesys­
       tems  may effect the response time without changing either
       the load or the mix.

       To do a comparison  of  different  server  configurations,
       first  set up the client test directories and do nhfsstone
       runs at different loads to be sure that the variability is
       reasonably  low.  Second, run nhfsstone at different loads
       of interest and save the results. Third, change the server
       configuration  (for  example,  add  more memory, replace a
       disk controller, etc.). Finally, run  the  same  nhfsstone
       loads again and compare the results.


       The  nhfsstone.c source file has comments that describe in
       detail the operation of of the program.


       illegal calls value
              The calls argument following the  -c  flag  on  the
              command line is not a positive number.

       illegal load value
              The load argument following the -l flag on the com­
              mand line is not a positive number.

       illegal time value
              The time argument following the -t flag on the com­
              mand line is not a positive number.

       bad mix file
              The  mixfile file argument following the -m flag on
              the command line could not be accessed.

       can't find current directory
              The parent process couldn't find  the  pathname  of
              the  current  directory.   This usually indicates a
              permission problem.

       can't fork
              The parent couldn't fork the child processes.  This
              usually  results  from  lack  of resources, such as
              memory or swap space.

       can't create test directory
       can't cd to test directory
       wrong permissions on test dir
       can't stat testfile
       wrong permissions on testfile
       can't create rename file
       can't create subdir
              A child process had problems creating  or  checking
              the contents of its test directory. This is usually
              due to a permission problem (for example  the  test
              directory  was  created  by  a different user) or a
              full filesystem.

       bad mix format: unexpected EOF after 'nfs:'
       bad mix format: can't find 'calls' value
       bad mix format: unexpected EOF after 'calls'
       bad mix format: can't find %d op values
       bad mix format: unexpected EOF
              A problem occurred while parsing the mix file.  The
              expected format of the file is the same as the out­
              put of the nfsstat(8C) command when  run  with  the
              "-s" option.

       op failed:
              One  of  the internal pseudo-NFS operations failed.
              The  name  of  the  operation,  e.g.  read,  write,
              lookup, will be printed along with an indication of
              the nature of the failure.

       select failed
              The  select  system  call  returned  an  unexpected


       Running  nhfsstone  on  a non-NFS filesystem can cause the
       program to run forever because  it  uses  the  kernel  NFS
       statistics  to determine when enough calls have been made.

       Nhfsstone uses many file descriptors. The  kernel  on  the
       client  may have to be reconfigured to increase the number
       of available file table entries.

       Shell scripts that used nhfsstone will have to  catch  and
       ignore  SIGUSR1  (see  signal(3)).  This signal is used to
       synchronize the test  processes.  If  the  signal  is  not
       caught  the  shell  that  is  running  the  script will be


       /vmunix             system namelist
       /dev/kmem           kernel virtual memory
       ./testdir*          per process test directory

More information about the site can be found in the FAQ



Security Code
Security Code
Type Security Code

Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!

Amazon Wish List

Did You Know?
The Linux Tutorial can use your help.


Tell a Friend About Us

Bookmark and Share

Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.10 Seconds