X-Git-Url: http://git.tuebingen.mpg.de/?a=blobdiff_plain;ds=sidebyside;f=Filesystems.m4;h=e2ac56198451a3f2bee58d0bbc764399aa86958d;hb=4c316f160f0712366f5a35eadef2ce0dbe21f278;hp=860fc6289ee50c25b894380079e0b77fe958df7d;hpb=e9a3585174e0fda1ac580d0e720f7ecc48bb9e9f;p=aple.git diff --git a/Filesystems.m4 b/Filesystems.m4 index 860fc62..e2ac561 100644 --- 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 dentry cache, 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.
+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.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 -RCU-walk is employed. With RCU, lookups can be performed -without taking locks, and read operations can proceed in parallel -with concurrent writers.
+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 RCU-walk is +employed. With RCU, lookups can be performed without taking locks, and +read operations can proceed in parallel with concurrent writers. The dentry cache also contains negative entries
which represent nonexistent paths which were recently looked up
unsuccessfully. When a user space program tries to access such a path
again, the ENOENT
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.
Dentries are reference-counted. As long as there is a reference -on a dentry, it can not be pruned from the dentry cache.
+failing such lookups quickly enhances performance. For example +import
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.
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.
+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.
+ SUBSECTION(«Reverse Mapping»)This feature was implemented in 2018. It adds yet another B-tree to @@ -1460,6 +1469,9 @@ SECTION(«Further Reading»)
Documentation/filesystems/vfs.txt
of the Linux
kernel source.