• Home
  • History
  • Annotate
Name Date Size #Lines LOC

..--

bin/22-Nov-2023-606409

bind/22-Nov-2023-2,7181,595

cloneNS/22-Nov-2023-1,271835

move/22-Nov-2023-2,1631,288

rbind/22-Nov-2023-4,2802,533

regression/22-Nov-2023-274159

.gitignoreD22-Nov-202325 32

BUGSD22-Nov-2023245 65

CHANGELOGD22-Nov-20233.1 KiB8555

MakefileD22-Nov-20231.1 KiB346

READMED22-Nov-20235.1 KiB166140

TODOD22-Nov-2023424 127

README

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