1================================================================= 2Test Suite for Bind Mount and Shared Subtree Features in the VFS: 3================================================================= 4Author: Avantika Mathur 5Date: September 16, 2005 6Last update: March 18th, 2008 (by Matt Helsley) 7 8About: 9------ 10These tests exercise the Linux Kernel's bind mount and shared subtree 11capabilities. With it administrators may use clear semantics to manage 12complex mount trees on a system. 13 14Bind mount simply allows administrators to make a directory appear in 15two 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 21a 22 23Note that bind mounts are not recursive. To get a recursive bind mount 24use --rbind. 25 26Another 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 33a foo 34# mkdir sub 35# touch sub/b 36# mount --bind sub /mnt/foo 37# ls mnt/foo 38b 39# ls mnt2/foo 40 41mnt2/foo appears to be empty because the second bind mount did not propagate 42to mnt2. Shared subtrees allow propagation whereas bind mounts do not. 43To enable full administrator control of propagation there are several kinds of 44subtrees: 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 50For further details on these types of subtrees please see your kernel source's 51Documentation/filesystems/sharedsubtree.txt file. 52 53Building: 54--------- 55Uses GNU Make. In the root directory type: 56make 57 58Installing: 59----------- 60Type: 61make install 62 63Cleaning: 64--------- 65Type: 66make clean 67 68Running: 69-------- 70run LTPROOT/testscripts/test_fs_bind.sh 71 72 73Testcases: 74---------- 75There are multiple testcases testing in each of the following categories, 76testing functionality of different types of mounts, different combinations, 77etc: 78-- bind 79-- rbind 80-- move 81-- regression tests 82-- clone namespace (currently not run) 83 84 85Directory Structure: 86-------------------- 87In 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 88indications are passed to the LTP API and logged in the results directory too. 89 90Basic tests of bind and move mounts are part of the test_fs_bind.sh test 91script itself. These are prerequisites for the more the complicated tests. 92The bind, rbind, and move directories contain tests for bind, rbind, move in 93combination with the various kinds of subtrees. The regression and cloneNS 94directories perform basic regression tests and combine some of the tests with 95mount namespaces respectively. 96 97The bin directory contains scripts used by each of the testcases for 98common setup, creating, and comparing mounts. 99 100Running the Test Suite: 101----------------------- 102To run the entire testsuite run: 103test_fs_bind.sh 104 105Log directories where the results are stored in LTPROOT/results/fs_bind 106 107Reading the Test Suite Results: 108------------------------------- 109Test suite results are logged, by default, in the LTPROOT/results/fs_bind 110directory. Its structure is: 111fs_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 133An testXX/err file will only be left for those tests that had errors and 134stderr was non-empty. mounts.*, files.*, and dirs.* files will be left for 135tests that appear to have broken cleanup sections. The test_fs_bind.sh 136script robustly handles cleanup so, unless the tests are run individually, this 137is not an issue that prevents testing from completing successfully nor does it 138interfere with test results. 139 140These files make it easy to determine what happened during a given test. 141It's easy to see which tests need to be debugged and which do not. It also 142makes it easy to aggregate output or trace sandbox dirtying from test to test. 143 144Running individual Tests: 145------------------------- 146Currently tests cannot be run individually because there are several important 147LTP 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 160It's important to note that the individual test scripts use the current working 161directory extensively but never exit it. This may allow the tests to be run 162individually once the above LTP environment dependencies are resolved. 163Lastly none of the logging or debugging information will appear in the 164LTPROOT/results/fs_bind directory when tests are invoked individually since 165those are collected by the test_fs_bind.sh script. 166