Home | History | Annotate | only in /external/ltp/testcases/kernel/fs/fs_bind
Up to higher level directory
NameDateSize
bin/21-Aug-2018
bind/21-Aug-2018
BUGS21-Aug-2018245
CHANGELOG21-Aug-20183.1K
cloneNS/21-Aug-2018
Makefile21-Aug-20181.1K
move/21-Aug-2018
rbind/21-Aug-2018
README21-Aug-20185.1K
regression/21-Aug-2018
TODO21-Aug-2018424

README

      1 =================================================================
      2 Test Suite for Bind Mount and Shared Subtree Features in the VFS:
      3 =================================================================
      4 Author: Avantika Mathur
      5 Date: September 16, 2005
      6 Last update: March 18th, 2008 (by Matt Helsley)
      7 
      8 About:
      9 ------
     10 These tests exercise the Linux Kernel's bind mount and shared subtree
     11 capabilities. With it administrators may use clear semantics to manage
     12 complex mount trees on a system.
     13 
     14 Bind mount simply allows administrators to make a directory appear in
     15 two places at once -- somewhat like hard links for files:
     16 
     17 # mkdir mnt mnt2
     18 # mount --bind mnt mnt2
     19 # touch mnt/a
     20 # ls mnt2
     21 a
     22 
     23 Note that bind mounts are not recursive. To get a recursive bind mount
     24 use --rbind.
     25 
     26 Another limitation of simple bind mounts is they cannot propagate future binds:
     27 
     28 # mkdir mnt mnt2
     29 # mount --bind mnt mnt2
     30 # touch mnt/a
     31 # mkdir mnt/foo
     32 # ls mnt2
     33 a foo
     34 # mkdir sub
     35 # touch sub/b
     36 # mount --bind sub /mnt/foo
     37 # ls mnt/foo
     38 b
     39 # ls mnt2/foo
     40 
     41 mnt2/foo appears to be empty because the second bind mount did not propagate
     42 to mnt2. Shared subtrees allow propagation whereas bind mounts do not.
     43 To enable full administrator control of propagation there are several kinds of
     44 subtrees:
     45 	private		[default -- this is a "normal" mount]
     46 	shared		[propagation goes both ways]
     47 	slave		[propagation goes one way]
     48 	unbindable	[cannot --bind and hence cannot share]
     49 
     50 For further details on these types of subtrees please see your kernel source's
     51 Documentation/filesystems/sharedsubtree.txt file.
     52 
     53 Building:
     54 ---------
     55 Uses GNU Make. In the root directory type:
     56 make
     57 
     58 Installing:
     59 -----------
     60 Type:
     61 make install
     62 
     63 Cleaning:
     64 ---------
     65 Type:
     66 make clean
     67 
     68 Running:
     69 --------
     70 run LTPROOT/testscripts/test_fs_bind.sh
     71 
     72 
     73 Testcases:
     74 ----------
     75 There are multiple testcases testing in each of the following categories,
     76 testing functionality of different types of mounts, different combinations,
     77 etc:
     78 -- bind
     79 -- rbind
     80 -- move
     81 -- regression tests
     82 -- clone namespace (currently not run)
     83 
     84 
     85 Directory Structure:
     86 --------------------
     87 In the root directory of the suite there are scripts to execute the whole test suite. Logged results are stored in LTPROOT/results/fs_bind. PASS/FAIL
     88 indications are passed to the LTP API and logged in the results directory too.
     89 
     90 Basic tests of bind and move mounts are part of the test_fs_bind.sh test
     91 script itself. These are prerequisites for the more the complicated tests.
     92 The bind, rbind, and move directories contain tests for bind, rbind, move in
     93 combination with the various kinds of subtrees. The regression and cloneNS
     94 directories perform basic regression tests and combine some of the tests with
     95 mount namespaces respectively.
     96 
     97 The bin directory contains scripts used by each of the testcases for
     98 common setup, creating, and comparing mounts.
     99 
    100 Running the Test Suite:
    101 -----------------------
    102 To run the entire testsuite run:
    103 test_fs_bind.sh
    104 
    105 Log directories where the results are stored in LTPROOT/results/fs_bind
    106 
    107 Reading the Test Suite Results:
    108 -------------------------------
    109 Test suite results are logged, by default, in the LTPROOT/results/fs_bind
    110 directory. Its structure is:
    111 fs_bind-\
    112 	|-> errors		 (stderr of main test suite script itself)
    113 	|-> summary		 (stdout of main test suite script itself)
    114 	|-move--\
    115 	|	|->test01-\	(logs of test01)
    116 	|	|	  |-> log		(stdout)
    117 	|	|	  |-> err		(stderr)
    118 	|	|	  |-> mtab.before
    119 	|	|	  |-> mtab.after
    120 	|	|	  |-> proc_mounts.before
    121 	|	|	  |-> proc_mounts.after
    122 	|	|	  |-> files.before	(files  before running)
    123 	|	|	  |-> dirs.before	(dirs   before running)
    124 	|	|	  |-> files.after	(files  after  running)
    125 	|	|	  \-> dirs.after	(dirs   after  running)
    126 	|	|->test02-\
    127 	|	|	  |
    128 	|	...	  ...
    129 	|-rbind--\
    130 	|        |-->
    131 	...       ...
    132 
    133 An testXX/err file will only be left for those tests that had errors and
    134 stderr was non-empty. mounts.*, files.*, and dirs.* files will be left for
    135 tests that appear to have broken cleanup sections. The test_fs_bind.sh
    136 script robustly handles cleanup so, unless the tests are run individually, this
    137 is not an issue that prevents testing from completing successfully nor does it
    138 interfere with test results.
    139 
    140 These files make it easy to determine what happened during a given test.
    141 It's easy to see which tests need to be debugged and which do not. It also
    142 makes it easy to aggregate output or trace sandbox dirtying from test to test.
    143 
    144 Running individual Tests:
    145 -------------------------
    146 Currently tests cannot be run individually because there are several important
    147 LTP environment dependencies. Some of them are documented below:
    148 	LTP test script environment variables:
    149 		LTPROOT
    150 		TCID
    151 		TST_TOTAL
    152 		TST_COUNT
    153 	LTP commands/functions:
    154 		tst_resm
    155 		tst_brkm
    156 		tst_exit
    157 	LTP contents:
    158 		LTPROOT/testcases/bin
    159 
    160 It's important to note that the individual test scripts use the current working
    161 directory extensively but never exit it. This may allow the tests to be run
    162 individually once the above LTP environment dependencies are resolved.
    163 Lastly none of the logging or debugging information will appear in the
    164 LTPROOT/results/fs_bind directory when tests are invoked individually since
    165 those are collected by the test_fs_bind.sh script.
    166