Lines Matching full:directory
2 Directory Locking
6 Locking scheme used for directory operations is based on two
10 When taking the i_rwsem on multiple non-directory objects, we
22 * lock the directory we are accessing (shared)
26 * lock the directory we are accessing (exclusive)
37 * check that the source is not a directory
40 5. rename that is _not_ cross-directory. Locking rules:
45 The source needs to be locked if it's a non-directory, target - if it's
46 a non-directory or about to be removed.
50 otherwise and the target because mixing directory and non-directory is
53 6. cross-directory rename. The trickiest in the whole bunch. Locking rules:
74 operations on directory trees, but we obviously do not have the full
83 possibility that directory we see in one place gets moved by the server
86 For a lot of reasons we want to have the same directory present in dcache
90 a root of separate tree, it gets attached to the directory we are doing a
92 a child of the directory we are looking in, it changes name to the one
94 However, if it's a child of some other directory, the things get trickier.
95 First of all, we verify that it is *not* an ancestor of our directory
99 attach to our directory, under the name we are looking for.
102 all we change is the view in dcache. Moreover, holding a directory locked
105 root of one tree becoming a child of directory in another. In particular,
108 the lock is dropped. So from the directory operations' point of view
110 step in cross-directory renames; we need to be careful when checking if
117 For some filesystems a method can involve a directory operation on
122 directory operation on this filesystem might involve directory operations
124 it should be possible to rank the filesystems so that directory operation
125 on a filesystem could trigger directory operations only on higher-ranked
133 If no directory is its own ancestor, the scheme above is deadlock-free.
143 lower than ->i_rwsem of any non-directory on the same filesystem.
186 one directory and blocked on attempt to lock another. That leaves
187 only 3 possible operations: directory removal (locks parent, then
188 child), same-directory rename killing a subdirectory (ditto) and
189 cross-directory rename of some sort.
191 There must be a cross-directory rename in the set; indeed,
195 have changed since the moment directory locks had been acquired,
200 more than one cross-directory rename among them. Without loss of
201 generality we can assume that T1 is the one doing a cross-directory
204 In other words, we have a cross-directory rename that locked
208 cross-directory rename does not get to locking any directories until it
214 cross-directory rename; parents first, then possibly their children.
239 Note that the check for having a common ancestor in cross-directory
244 descendent of the parent of target. At that point we have cross-directory
254 the only operation that could introduce loops is cross-directory rename.
278 ability to check that directory is a descendent of another object. Current
279 implementation assumes that directory graph is a tree. This assumption is
280 also preserved by all operations (cross-directory rename on a tree that would
283 Notice that "directory" in the above == "anything that might have