Lines Matching refs:upper

25 upper filesystem that is providing the object.  Similarly st_ino will
53 An overlay filesystem combines two filesystems - an 'upper' filesystem
55 object in the 'upper' filesystem is visible while the object in the
57 merged with the 'upper' object.
59 It would be more correct to refer to an upper and lower 'directory
62 requirement that the root of a filesystem be given for either upper or
67 overlayfs.  The upper filesystem will normally be writable and if it
78 upper and lower filesystems and refers to a non-directory in either,
79 then the lower object is hidden - the name refers only to the upper
82 Where both upper and lower objects are directories, a merged directory
88   mount -t overlay overlay -olowerdir=/lower,upperdir=/upper,\
98 directory is created, otherwise only one is stored: the upper if it
102 such as metadata and extended attributes are reported for the upper
109 filesystem, an overlay filesystem needs to record in the upper filesystem
114 When a whiteout is found in the upper level of a merged directory, any
119 to "y".  Where the upper filesystem contains an opaque directory, any
125 When a 'readdir' request is made on a merged directory, the upper and
127 obvious way (upper is read first, then lower - entries that already
152 underlying directory (upper or lower).
158 directory was not created on the upper layer to start with) overlayfs can
208 upper directory is stored in a "trusted.overlay.upper" extended attribute
209 on the index entry.  On lookup of a merged directory, if the upper
211 indication that multiple upper directories may be redirected to the same
216 NFS export support on an overlay filesystem with no upper layer requires
224 files etc.) are presented either from the upper or lower filesystem as
228 to the upper filesystem (copy_up).  Note that creating a hard-link
236 exists in the upper filesystem - creating it and any parents as
239 data is copied from the lower to the upper filesystem.  Finally any
243 provides direct access to the newly created file in the upper
282 Do not use metacopy=on with untrusted upper/lower directories. Otherwise
297 Using an upper layer path and/or a workdir path that are already used by
301 upper layer and/or workdir path the behavior of the overlay is undefined,
304 Mounting an overlay using an upper layer path, where the upper layer path
312 attribute on the upper layer root directory.  On subsequent mount attempts,
314 to the stored origin in upper root directory.  On failure to verify the
318 if the upper filesystem does not support extended attributes.
321 mount time. So if same upper is mounted with different set of lower, mount
373 the upper or the lower trees.
386 attribute "trusted.overlay.origin" on the upper inode.
394 will not be merged with the upper directory.
407 non-directory object, the index entry is a hard link to the upper inode.
409 "trusted.overlay.upper" with an encoded file handle of the upper
415 1. For a non-upper object, encode a lower file handle from lower inode
417 3. For a pure-upper object and for an existing non-indexed upper object,
418    encode an upper file handle from upper inode
421  - Header including path type information (e.g. lower/upper)
441 copy_up of that disconnected dentry will create an upper index entry with
442 no upper alias.
447 "redirect" origin directory, cannot be used to find the middle or upper
452 directories are copied up on encode and encoded as an upper file handle.
453 On an overlay filesystem with no upper layer this mitigation cannot be
462 verified on mount time to check that upper file handles are not stale.