diff options
author | James Bottomley <jejb@mulgrave.il.steeleye.com> | 2006-11-22 13:06:44 -0500 |
---|---|---|
committer | James Bottomley <jejb@mulgrave.il.steeleye.com> | 2006-11-22 13:06:44 -0500 |
commit | 0bd2af46839ad6262d25714a6ec0365db9d6b98f (patch) | |
tree | dcced72d230d69fd0c5816ac6dd03ab84799a93e /Documentation/DocBook | |
parent | e138a5d2356729b8752e88520cc1525fae9794ac (diff) | |
parent | f26b90440cd74c78fe10c9bd5160809704a9627c (diff) |
Merge ../scsi-rc-fixes-2.6
Diffstat (limited to 'Documentation/DocBook')
-rw-r--r-- | Documentation/DocBook/Makefile | 2 | ||||
-rw-r--r-- | Documentation/DocBook/filesystems.tmpl (renamed from Documentation/DocBook/journal-api.tmpl) | 252 | ||||
-rw-r--r-- | Documentation/DocBook/kernel-api.tmpl | 60 |
3 files changed, 161 insertions, 153 deletions
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 66e1cf733571..db9499adbed4 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile | |||
@@ -9,7 +9,7 @@ | |||
9 | DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \ | 9 | DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \ |
10 | kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ | 10 | kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ |
11 | procfs-guide.xml writing_usb_driver.xml \ | 11 | procfs-guide.xml writing_usb_driver.xml \ |
12 | kernel-api.xml journal-api.xml lsm.xml usb.xml \ | 12 | kernel-api.xml filesystems.xml lsm.xml usb.xml \ |
13 | gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ | 13 | gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ |
14 | genericirq.xml | 14 | genericirq.xml |
15 | 15 | ||
diff --git a/Documentation/DocBook/journal-api.tmpl b/Documentation/DocBook/filesystems.tmpl index 2077f9a28c19..39fa2aba7f9b 100644 --- a/Documentation/DocBook/journal-api.tmpl +++ b/Documentation/DocBook/filesystems.tmpl | |||
@@ -2,39 +2,11 @@ | |||
2 | <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" | 2 | <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" |
3 | "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> | 3 | "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> |
4 | 4 | ||
5 | <book id="LinuxJBDAPI"> | 5 | <book id="Linux-filesystems-API"> |
6 | <bookinfo> | 6 | <bookinfo> |
7 | <title>The Linux Journalling API</title> | 7 | <title>Linux Filesystems API</title> |
8 | <authorgroup> | ||
9 | <author> | ||
10 | <firstname>Roger</firstname> | ||
11 | <surname>Gammans</surname> | ||
12 | <affiliation> | ||
13 | <address> | ||
14 | <email>rgammans@computer-surgery.co.uk</email> | ||
15 | </address> | ||
16 | </affiliation> | ||
17 | </author> | ||
18 | </authorgroup> | ||
19 | |||
20 | <authorgroup> | ||
21 | <author> | ||
22 | <firstname>Stephen</firstname> | ||
23 | <surname>Tweedie</surname> | ||
24 | <affiliation> | ||
25 | <address> | ||
26 | <email>sct@redhat.com</email> | ||
27 | </address> | ||
28 | </affiliation> | ||
29 | </author> | ||
30 | </authorgroup> | ||
31 | 8 | ||
32 | <copyright> | 9 | <legalnotice> |
33 | <year>2002</year> | ||
34 | <holder>Roger Gammans</holder> | ||
35 | </copyright> | ||
36 | |||
37 | <legalnotice> | ||
38 | <para> | 10 | <para> |
39 | This documentation is free software; you can redistribute | 11 | This documentation is free software; you can redistribute |
40 | it and/or modify it under the terms of the GNU General Public | 12 | it and/or modify it under the terms of the GNU General Public |
@@ -42,21 +14,21 @@ | |||
42 | version 2 of the License, or (at your option) any later | 14 | version 2 of the License, or (at your option) any later |
43 | version. | 15 | version. |
44 | </para> | 16 | </para> |
45 | 17 | ||
46 | <para> | 18 | <para> |
47 | This program is distributed in the hope that it will be | 19 | This program is distributed in the hope that it will be |
48 | useful, but WITHOUT ANY WARRANTY; without even the implied | 20 | useful, but WITHOUT ANY WARRANTY; without even the implied |
49 | warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. | 21 | warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. |
50 | See the GNU General Public License for more details. | 22 | See the GNU General Public License for more details. |
51 | </para> | 23 | </para> |
52 | 24 | ||
53 | <para> | 25 | <para> |
54 | You should have received a copy of the GNU General Public | 26 | You should have received a copy of the GNU General Public |
55 | License along with this program; if not, write to the Free | 27 | License along with this program; if not, write to the Free |
56 | Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, | 28 | Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, |
57 | MA 02111-1307 USA | 29 | MA 02111-1307 USA |
58 | </para> | 30 | </para> |
59 | 31 | ||
60 | <para> | 32 | <para> |
61 | For more details see the file COPYING in the source | 33 | For more details see the file COPYING in the source |
62 | distribution of Linux. | 34 | distribution of Linux. |
@@ -66,17 +38,113 @@ | |||
66 | 38 | ||
67 | <toc></toc> | 39 | <toc></toc> |
68 | 40 | ||
69 | <chapter id="Overview"> | 41 | <chapter id="vfs"> |
42 | <title>The Linux VFS</title> | ||
43 | <sect1><title>The Filesystem types</title> | ||
44 | !Iinclude/linux/fs.h | ||
45 | </sect1> | ||
46 | <sect1><title>The Directory Cache</title> | ||
47 | !Efs/dcache.c | ||
48 | !Iinclude/linux/dcache.h | ||
49 | </sect1> | ||
50 | <sect1><title>Inode Handling</title> | ||
51 | !Efs/inode.c | ||
52 | !Efs/bad_inode.c | ||
53 | </sect1> | ||
54 | <sect1><title>Registration and Superblocks</title> | ||
55 | !Efs/super.c | ||
56 | </sect1> | ||
57 | <sect1><title>File Locks</title> | ||
58 | !Efs/locks.c | ||
59 | !Ifs/locks.c | ||
60 | </sect1> | ||
61 | <sect1><title>Other Functions</title> | ||
62 | !Efs/mpage.c | ||
63 | !Efs/namei.c | ||
64 | !Efs/buffer.c | ||
65 | !Efs/bio.c | ||
66 | !Efs/seq_file.c | ||
67 | !Efs/filesystems.c | ||
68 | !Efs/fs-writeback.c | ||
69 | !Efs/block_dev.c | ||
70 | </sect1> | ||
71 | </chapter> | ||
72 | |||
73 | <chapter id="proc"> | ||
74 | <title>The proc filesystem</title> | ||
75 | |||
76 | <sect1><title>sysctl interface</title> | ||
77 | !Ekernel/sysctl.c | ||
78 | </sect1> | ||
79 | |||
80 | <sect1><title>proc filesystem interface</title> | ||
81 | !Ifs/proc/base.c | ||
82 | </sect1> | ||
83 | </chapter> | ||
84 | |||
85 | <chapter id="sysfs"> | ||
86 | <title>The Filesystem for Exporting Kernel Objects</title> | ||
87 | !Efs/sysfs/file.c | ||
88 | !Efs/sysfs/symlink.c | ||
89 | !Efs/sysfs/bin.c | ||
90 | </chapter> | ||
91 | |||
92 | <chapter id="debugfs"> | ||
93 | <title>The debugfs filesystem</title> | ||
94 | |||
95 | <sect1><title>debugfs interface</title> | ||
96 | !Efs/debugfs/inode.c | ||
97 | !Efs/debugfs/file.c | ||
98 | </sect1> | ||
99 | </chapter> | ||
100 | |||
101 | <chapter id="LinuxJDBAPI"> | ||
102 | <chapterinfo> | ||
103 | <title>The Linux Journalling API</title> | ||
104 | |||
105 | <authorgroup> | ||
106 | <author> | ||
107 | <firstname>Roger</firstname> | ||
108 | <surname>Gammans</surname> | ||
109 | <affiliation> | ||
110 | <address> | ||
111 | <email>rgammans@computer-surgery.co.uk</email> | ||
112 | </address> | ||
113 | </affiliation> | ||
114 | </author> | ||
115 | </authorgroup> | ||
116 | |||
117 | <authorgroup> | ||
118 | <author> | ||
119 | <firstname>Stephen</firstname> | ||
120 | <surname>Tweedie</surname> | ||
121 | <affiliation> | ||
122 | <address> | ||
123 | <email>sct@redhat.com</email> | ||
124 | </address> | ||
125 | </affiliation> | ||
126 | </author> | ||
127 | </authorgroup> | ||
128 | |||
129 | <copyright> | ||
130 | <year>2002</year> | ||
131 | <holder>Roger Gammans</holder> | ||
132 | </copyright> | ||
133 | </chapterinfo> | ||
134 | |||
135 | <title>The Linux Journalling API</title> | ||
136 | |||
137 | <sect1> | ||
70 | <title>Overview</title> | 138 | <title>Overview</title> |
71 | <sect1> | 139 | <sect2> |
72 | <title>Details</title> | 140 | <title>Details</title> |
73 | <para> | 141 | <para> |
74 | The journalling layer is easy to use. You need to | 142 | The journalling layer is easy to use. You need to |
75 | first of all create a journal_t data structure. There are | 143 | first of all create a journal_t data structure. There are |
76 | two calls to do this dependent on how you decide to allocate the physical | 144 | two calls to do this dependent on how you decide to allocate the physical |
77 | media on which the journal resides. The journal_init_inode() call | 145 | media on which the journal resides. The journal_init_inode() call |
78 | is for journals stored in filesystem inodes, or the journal_init_dev() | 146 | is for journals stored in filesystem inodes, or the journal_init_dev() |
79 | call can be use for journal stored on a raw device (in a continuous range | 147 | call can be use for journal stored on a raw device (in a continuous range |
80 | of blocks). A journal_t is a typedef for a struct pointer, so when | 148 | of blocks). A journal_t is a typedef for a struct pointer, so when |
81 | you are finally finished make sure you call journal_destroy() on it | 149 | you are finally finished make sure you call journal_destroy() on it |
82 | to free up any used kernel memory. | 150 | to free up any used kernel memory. |
@@ -91,27 +159,26 @@ need to call journal_create(). | |||
91 | <para> | 159 | <para> |
92 | Most of the time however your journal file will already have been created, but | 160 | Most of the time however your journal file will already have been created, but |
93 | before you load it you must call journal_wipe() to empty the journal file. | 161 | before you load it you must call journal_wipe() to empty the journal file. |
94 | Hang on, you say , what if the filesystem wasn't cleanly umount()'d . Well, it is the | 162 | Hang on, you say , what if the filesystem wasn't cleanly umount()'d . Well, it is the |
95 | job of the client file system to detect this and skip the call to journal_wipe(). | 163 | job of the client file system to detect this and skip the call to journal_wipe(). |
96 | </para> | 164 | </para> |
97 | 165 | ||
98 | <para> | 166 | <para> |
99 | In either case the next call should be to journal_load() which prepares the | 167 | In either case the next call should be to journal_load() which prepares the |
100 | journal file for use. Note that journal_wipe(..,0) calls journal_skip_recovery() | 168 | journal file for use. Note that journal_wipe(..,0) calls journal_skip_recovery() |
101 | for you if it detects any outstanding transactions in the journal and similarly | 169 | for you if it detects any outstanding transactions in the journal and similarly |
102 | journal_load() will call journal_recover() if necessary. | 170 | journal_load() will call journal_recover() if necessary. |
103 | I would advise reading fs/ext3/super.c for examples on this stage. | 171 | I would advise reading fs/ext3/super.c for examples on this stage. |
104 | [RGG: Why is the journal_wipe() call necessary - doesn't this needlessly | 172 | [RGG: Why is the journal_wipe() call necessary - doesn't this needlessly |
105 | complicate the API. Or isn't a good idea for the journal layer to hide | 173 | complicate the API. Or isn't a good idea for the journal layer to hide |
106 | dirty mounts from the client fs] | 174 | dirty mounts from the client fs] |
107 | </para> | 175 | </para> |
108 | 176 | ||
109 | <para> | 177 | <para> |
110 | Now you can go ahead and start modifying the underlying | 178 | Now you can go ahead and start modifying the underlying |
111 | filesystem. Almost. | 179 | filesystem. Almost. |
112 | </para> | 180 | </para> |
113 | 181 | ||
114 | |||
115 | <para> | 182 | <para> |
116 | 183 | ||
117 | You still need to actually journal your filesystem changes, this | 184 | You still need to actually journal your filesystem changes, this |
@@ -138,10 +205,10 @@ individual buffers (blocks). Before you start to modify a buffer you | |||
138 | need to call journal_get_{create,write,undo}_access() as appropriate, | 205 | need to call journal_get_{create,write,undo}_access() as appropriate, |
139 | this allows the journalling layer to copy the unmodified data if it | 206 | this allows the journalling layer to copy the unmodified data if it |
140 | needs to. After all the buffer may be part of a previously uncommitted | 207 | needs to. After all the buffer may be part of a previously uncommitted |
141 | transaction. | 208 | transaction. |
142 | At this point you are at last ready to modify a buffer, and once | 209 | At this point you are at last ready to modify a buffer, and once |
143 | you are have done so you need to call journal_dirty_{meta,}data(). | 210 | you are have done so you need to call journal_dirty_{meta,}data(). |
144 | Or if you've asked for access to a buffer you now know is now longer | 211 | Or if you've asked for access to a buffer you now know is now longer |
145 | required to be pushed back on the device you can call journal_forget() | 212 | required to be pushed back on the device you can call journal_forget() |
146 | in much the same way as you might have used bforget() in the past. | 213 | in much the same way as you might have used bforget() in the past. |
147 | </para> | 214 | </para> |
@@ -156,7 +223,6 @@ Then at umount time , in your put_super() (2.4) or write_super() (2.5) | |||
156 | you can then call journal_destroy() to clean up your in-core journal object. | 223 | you can then call journal_destroy() to clean up your in-core journal object. |
157 | </para> | 224 | </para> |
158 | 225 | ||
159 | |||
160 | <para> | 226 | <para> |
161 | Unfortunately there a couple of ways the journal layer can cause a deadlock. | 227 | Unfortunately there a couple of ways the journal layer can cause a deadlock. |
162 | The first thing to note is that each task can only have | 228 | The first thing to note is that each task can only have |
@@ -164,19 +230,19 @@ a single outstanding transaction at any one time, remember nothing | |||
164 | commits until the outermost journal_stop(). This means | 230 | commits until the outermost journal_stop(). This means |
165 | you must complete the transaction at the end of each file/inode/address | 231 | you must complete the transaction at the end of each file/inode/address |
166 | etc. operation you perform, so that the journalling system isn't re-entered | 232 | etc. operation you perform, so that the journalling system isn't re-entered |
167 | on another journal. Since transactions can't be nested/batched | 233 | on another journal. Since transactions can't be nested/batched |
168 | across differing journals, and another filesystem other than | 234 | across differing journals, and another filesystem other than |
169 | yours (say ext3) may be modified in a later syscall. | 235 | yours (say ext3) may be modified in a later syscall. |
170 | </para> | 236 | </para> |
171 | 237 | ||
172 | <para> | 238 | <para> |
173 | The second case to bear in mind is that journal_start() can | 239 | The second case to bear in mind is that journal_start() can |
174 | block if there isn't enough space in the journal for your transaction | 240 | block if there isn't enough space in the journal for your transaction |
175 | (based on the passed nblocks param) - when it blocks it merely(!) needs to | 241 | (based on the passed nblocks param) - when it blocks it merely(!) needs to |
176 | wait for transactions to complete and be committed from other tasks, | 242 | wait for transactions to complete and be committed from other tasks, |
177 | so essentially we are waiting for journal_stop(). So to avoid | 243 | so essentially we are waiting for journal_stop(). So to avoid |
178 | deadlocks you must treat journal_start/stop() as if they | 244 | deadlocks you must treat journal_start/stop() as if they |
179 | were semaphores and include them in your semaphore ordering rules to prevent | 245 | were semaphores and include them in your semaphore ordering rules to prevent |
180 | deadlocks. Note that journal_extend() has similar blocking behaviour to | 246 | deadlocks. Note that journal_extend() has similar blocking behaviour to |
181 | journal_start() so you can deadlock here just as easily as on journal_start(). | 247 | journal_start() so you can deadlock here just as easily as on journal_start(). |
182 | </para> | 248 | </para> |
@@ -184,7 +250,7 @@ journal_start() so you can deadlock here just as easily as on journal_start(). | |||
184 | <para> | 250 | <para> |
185 | Try to reserve the right number of blocks the first time. ;-). This will | 251 | Try to reserve the right number of blocks the first time. ;-). This will |
186 | be the maximum number of blocks you are going to touch in this transaction. | 252 | be the maximum number of blocks you are going to touch in this transaction. |
187 | I advise having a look at at least ext3_jbd.h to see the basis on which | 253 | I advise having a look at at least ext3_jbd.h to see the basis on which |
188 | ext3 uses to make these decisions. | 254 | ext3 uses to make these decisions. |
189 | </para> | 255 | </para> |
190 | 256 | ||
@@ -193,13 +259,13 @@ Another wriggle to watch out for is your on-disk block allocation strategy. | |||
193 | why? Because, if you undo a delete, you need to ensure you haven't reused any | 259 | why? Because, if you undo a delete, you need to ensure you haven't reused any |
194 | of the freed blocks in a later transaction. One simple way of doing this | 260 | of the freed blocks in a later transaction. One simple way of doing this |
195 | is make sure any blocks you allocate only have checkpointed transactions | 261 | is make sure any blocks you allocate only have checkpointed transactions |
196 | listed against them. Ext3 does this in ext3_test_allocatable(). | 262 | listed against them. Ext3 does this in ext3_test_allocatable(). |
197 | </para> | 263 | </para> |
198 | 264 | ||
199 | <para> | 265 | <para> |
200 | Lock is also providing through journal_{un,}lock_updates(), | 266 | Lock is also providing through journal_{un,}lock_updates(), |
201 | ext3 uses this when it wants a window with a clean and stable fs for a moment. | 267 | ext3 uses this when it wants a window with a clean and stable fs for a moment. |
202 | eg. | 268 | eg. |
203 | </para> | 269 | </para> |
204 | 270 | ||
205 | <programlisting> | 271 | <programlisting> |
@@ -230,19 +296,19 @@ extend it like this:- | |||
230 | struct journal_callback for_jbd; | 296 | struct journal_callback for_jbd; |
231 | // Stuff for myfs allocated together. | 297 | // Stuff for myfs allocated together. |
232 | myfs_inode* i_commited; | 298 | myfs_inode* i_commited; |
233 | 299 | ||
234 | } | 300 | } |
235 | </programlisting> | 301 | </programlisting> |
236 | 302 | ||
237 | <para> | 303 | <para> |
238 | this would be useful if you needed to know when data was committed to a | 304 | this would be useful if you needed to know when data was committed to a |
239 | particular inode. | 305 | particular inode. |
240 | </para> | 306 | </para> |
241 | 307 | ||
242 | </sect1> | 308 | </sect2> |
243 | 309 | ||
244 | <sect1> | 310 | <sect2> |
245 | <title>Summary</title> | 311 | <title>Summary</title> |
246 | <para> | 312 | <para> |
247 | Using the journal is a matter of wrapping the different context changes, | 313 | Using the journal is a matter of wrapping the different context changes, |
248 | being each mount, each modification (transaction) and each changed buffer | 314 | being each mount, each modification (transaction) and each changed buffer |
@@ -260,15 +326,15 @@ an example. | |||
260 | if (clean) journal_wipe(); | 326 | if (clean) journal_wipe(); |
261 | journal_load(); | 327 | journal_load(); |
262 | 328 | ||
263 | foreach(transaction) { /*transactions must be | 329 | foreach(transaction) { /*transactions must be |
264 | completed before | 330 | completed before |
265 | a syscall returns to | 331 | a syscall returns to |
266 | userspace*/ | 332 | userspace*/ |
267 | 333 | ||
268 | handle_t * xct=journal_start(my_jnrl); | 334 | handle_t * xct=journal_start(my_jnrl); |
269 | foreach(bh) { | 335 | foreach(bh) { |
270 | journal_get_{create,write,undo}_access(xact,bh); | 336 | journal_get_{create,write,undo}_access(xact,bh); |
271 | if ( myfs_modify(bh) ) { /* returns true | 337 | if ( myfs_modify(bh) ) { /* returns true |
272 | if makes changes */ | 338 | if makes changes */ |
273 | journal_dirty_{meta,}data(xact,bh); | 339 | journal_dirty_{meta,}data(xact,bh); |
274 | } else { | 340 | } else { |
@@ -279,55 +345,57 @@ an example. | |||
279 | } | 345 | } |
280 | journal_destroy(my_jrnl); | 346 | journal_destroy(my_jrnl); |
281 | </programlisting> | 347 | </programlisting> |
282 | </sect1> | 348 | </sect2> |
283 | 349 | ||
284 | </chapter> | 350 | </sect1> |
285 | 351 | ||
286 | <chapter id="adt"> | 352 | <sect1> |
287 | <title>Data Types</title> | 353 | <title>Data Types</title> |
288 | <para> | 354 | <para> |
289 | The journalling layer uses typedefs to 'hide' the concrete definitions | 355 | The journalling layer uses typedefs to 'hide' the concrete definitions |
290 | of the structures used. As a client of the JBD layer you can | 356 | of the structures used. As a client of the JBD layer you can |
291 | just rely on the using the pointer as a magic cookie of some sort. | 357 | just rely on the using the pointer as a magic cookie of some sort. |
292 | 358 | ||
293 | Obviously the hiding is not enforced as this is 'C'. | 359 | Obviously the hiding is not enforced as this is 'C'. |
294 | </para> | 360 | </para> |
295 | <sect1><title>Structures</title> | 361 | <sect2><title>Structures</title> |
296 | !Iinclude/linux/jbd.h | 362 | !Iinclude/linux/jbd.h |
297 | </sect1> | 363 | </sect2> |
298 | </chapter> | 364 | </sect1> |
299 | 365 | ||
300 | <chapter id="calls"> | 366 | <sect1> |
301 | <title>Functions</title> | 367 | <title>Functions</title> |
302 | <para> | 368 | <para> |
303 | The functions here are split into two groups those that | 369 | The functions here are split into two groups those that |
304 | affect a journal as a whole, and those which are used to | 370 | affect a journal as a whole, and those which are used to |
305 | manage transactions | 371 | manage transactions |
306 | </para> | 372 | </para> |
307 | <sect1><title>Journal Level</title> | 373 | <sect2><title>Journal Level</title> |
308 | !Efs/jbd/journal.c | 374 | !Efs/jbd/journal.c |
309 | !Ifs/jbd/recovery.c | 375 | !Ifs/jbd/recovery.c |
310 | </sect1> | 376 | </sect2> |
311 | <sect1><title>Transasction Level</title> | 377 | <sect2><title>Transasction Level</title> |
312 | !Efs/jbd/transaction.c | 378 | !Efs/jbd/transaction.c |
313 | </sect1> | 379 | </sect2> |
314 | </chapter> | 380 | </sect1> |
315 | <chapter> | 381 | <sect1> |
316 | <title>See also</title> | 382 | <title>See also</title> |
317 | <para> | 383 | <para> |
318 | <citation> | 384 | <citation> |
319 | <ulink url="ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/journal-design.ps.gz"> | 385 | <ulink url="ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/journal-design.ps.gz"> |
320 | Journaling the Linux ext2fs Filesystem,LinuxExpo 98, Stephen Tweedie | 386 | Journaling the Linux ext2fs Filesystem, LinuxExpo 98, Stephen Tweedie |
321 | </ulink> | 387 | </ulink> |
322 | </citation> | 388 | </citation> |
323 | </para> | 389 | </para> |
324 | <para> | 390 | <para> |
325 | <citation> | 391 | <citation> |
326 | <ulink url="http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html"> | 392 | <ulink url="http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html"> |
327 | Ext3 Journalling FileSystem , OLS 2000, Dr. Stephen Tweedie | 393 | Ext3 Journalling FileSystem, OLS 2000, Dr. Stephen Tweedie |
328 | </ulink> | 394 | </ulink> |
329 | </citation> | 395 | </citation> |
330 | </para> | 396 | </para> |
331 | </chapter> | 397 | </sect1> |
398 | |||
399 | </chapter> | ||
332 | 400 | ||
333 | </book> | 401 | </book> |
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index 2b5ac604948c..a166675c4303 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl | |||
@@ -182,66 +182,6 @@ X!Ilib/string.c | |||
182 | </sect1> | 182 | </sect1> |
183 | </chapter> | 183 | </chapter> |
184 | 184 | ||
185 | <chapter id="vfs"> | ||
186 | <title>The Linux VFS</title> | ||
187 | <sect1><title>The Filesystem types</title> | ||
188 | !Iinclude/linux/fs.h | ||
189 | </sect1> | ||
190 | <sect1><title>The Directory Cache</title> | ||
191 | !Efs/dcache.c | ||
192 | !Iinclude/linux/dcache.h | ||
193 | </sect1> | ||
194 | <sect1><title>Inode Handling</title> | ||
195 | !Efs/inode.c | ||
196 | !Efs/bad_inode.c | ||
197 | </sect1> | ||
198 | <sect1><title>Registration and Superblocks</title> | ||
199 | !Efs/super.c | ||
200 | </sect1> | ||
201 | <sect1><title>File Locks</title> | ||
202 | !Efs/locks.c | ||
203 | !Ifs/locks.c | ||
204 | </sect1> | ||
205 | <sect1><title>Other Functions</title> | ||
206 | !Efs/mpage.c | ||
207 | !Efs/namei.c | ||
208 | !Efs/buffer.c | ||
209 | !Efs/bio.c | ||
210 | !Efs/seq_file.c | ||
211 | !Efs/filesystems.c | ||
212 | !Efs/fs-writeback.c | ||
213 | !Efs/block_dev.c | ||
214 | </sect1> | ||
215 | </chapter> | ||
216 | |||
217 | <chapter id="proc"> | ||
218 | <title>The proc filesystem</title> | ||
219 | |||
220 | <sect1><title>sysctl interface</title> | ||
221 | !Ekernel/sysctl.c | ||
222 | </sect1> | ||
223 | |||
224 | <sect1><title>proc filesystem interface</title> | ||
225 | !Ifs/proc/base.c | ||
226 | </sect1> | ||
227 | </chapter> | ||
228 | |||
229 | <chapter id="sysfs"> | ||
230 | <title>The Filesystem for Exporting Kernel Objects</title> | ||
231 | !Efs/sysfs/file.c | ||
232 | !Efs/sysfs/symlink.c | ||
233 | !Efs/sysfs/bin.c | ||
234 | </chapter> | ||
235 | |||
236 | <chapter id="debugfs"> | ||
237 | <title>The debugfs filesystem</title> | ||
238 | |||
239 | <sect1><title>debugfs interface</title> | ||
240 | !Efs/debugfs/inode.c | ||
241 | !Efs/debugfs/file.c | ||
242 | </sect1> | ||
243 | </chapter> | ||
244 | |||
245 | <chapter id="relayfs"> | 185 | <chapter id="relayfs"> |
246 | <title>relay interface support</title> | 186 | <title>relay interface support</title> |
247 | 187 | ||