Networking: Remove exercise about www.meineip.de.

[aple.git] / Filesystems.m4

diff --git a/Filesystems.m4 b/Filesystems.m4
index 0e573d3d44ba3cd11499dae6e357f5451503931e..e2ac56198451a3f2bee58d0bbc764399aa86958d 100644 (file)
--- a/Filesystems.m4
+++ b/Filesystems.m4
@@ -543,30 +543,34 @@ SUBSECTION(«The Dentry Cache»)
 which represents a file or a directory. Dentries contain pointers to
 the corresponding inode and to the parent dentry. The vfs maintains
 the <em>dentry cache</em>, which is independent of the normal page
-cache that keeps copies of file contents in memory. Dentries are kept
-in hashed lists to make directory lookups fast. </p>
+cache that keeps copies of file contents in memory. Dentries are
+kept in hashed lists to make directory lookups fast. Dentries are
+also reference-counted. As long as there is a reference on a dentry,
+it can not be pruned from the dentry cache. Unreferenced dentries,
+however, can be evicted from the cache at any time due to memory
+pressure. Each dentry also has a "looked up" flag which enables the
+VFS to evict dentries which have never been looked up earlier than
+those which have. </p>
 
 <p> On a busy system the dentry cache changes frequently. For example,
 file creation, removal and rename all trigger an update of the dentry
-cache. Moreover, memory pressure can cause dentries to be evicted from
-the cache at any time. Clearly, some sort of coordination is needed to
-keep the dentry cache consistent in view of concurrent changes, like
-a file being deleted on one CPU and looked up on another. A global
-lock would scale very poorly, so a more sophisticated method called
-<em>RCU-walk</em> is employed. With RCU, lookups can be performed
-without taking locks, and read operations can proceed in parallel
-with concurrent writers. </p>
+cache. Clearly, some sort of coordination is needed to keep the dentry
+cache consistent in view of concurrent changes, like a file being
+deleted on one CPU and looked up on another. A global lock would scale
+very poorly, so a more sophisticated method called <em>RCU-walk</em> is
+employed. With RCU, lookups can be performed without taking locks, and
+read operations can proceed in parallel with concurrent writers. </p>
 
 <p> The dentry cache also contains <em>negative</em> entries
 which represent nonexistent paths which were recently looked up
 unsuccessfully. When a user space program tries to access such a path
 again, the <code>ENOENT</code> error can be returned without involving
 the filesystem. Since lookups of nonexistent files happen frequently,
-failing such lookups quickly enhances performance. Naturally, negative
-dentries do not point to any inode. </p>
-
-<p> Dentries are reference-counted. As long as there is a reference
-on a dentry, it can not be pruned from the dentry cache. </p>
+failing such lookups quickly enhances performance. For example
+<code>import</code> statements from interpreted languages like Python
+benefit from the negative entries of the dentry cache because the
+requested files have to be looked up in several directories. Naturally,
+negative dentries do not point to any inode. </p>
 
 SUBSECTION(«File and Inode Objects»)
 
@@ -951,6 +955,11 @@ file fragmentation, but they can cause confusion because they are
 accounted identically to other blocks, making files appear to use
 more data blocks than expected. </p>
 
+<p> If the system crashes while preallocated post-EOF blocks exist,
+the space will be recovered the next time the affected file gets closed
+(after it has been opened of course) by the normal reclaim mechanism
+which happens when a file is being closed. </p>
+
 SUBSECTION(«Reverse Mapping»)
 
 <p> This feature was implemented in 2018. It adds yet another B-tree to