Lines Matching refs:the
29 fm_start, and fm_length specify the logical range within the file
30 which the process would like mappings for. Extents returned mirror
31 those on disk - that is, the logical offset of the 1st returned extent
32 may start before fm_start, and the range covered by the last returned
35 Certain flags to modify the way in which mappings are looked up can be
36 set in fm_flags. If the kernel doesn't understand some particular
37 flags, it will return EBADR and the contents of fm_flags will contain
38 the set of flags which caused the error. If the kernel is compatible
39 with all flags passed, the contents of fm_flags will be unmodified.
41 flag is fatal to its operation. This scheme is intended to allow the
42 fiemap interface to grow in the future but without losing
45 fm_extent_count specifies the number of elements in the fm_extents[] array
46 that can be used to return extents. If fm_extent_count is zero, then the
47 fm_extents[] array is ignored (no extents will be returned), and the
48 fm_mapped_extents count will hold the number of extents needed in
49 fm_extents[] to hold the file's current mapping. Note that there is
50 nothing to prevent the file from changing between calls to FIEMAP.
55 If this flag is set, the kernel will sync the file before mapping extents.
58 If this flag is set, the extents returned will describe the inodes
65 Extent information is returned within the embedded fm_extents array
66 which userspace must allocate along with the fiemap structure. The
67 number of elements in the fiemap_extents[] array should be passed via
69 returned via fm_mapped_extents. If the number of fiemap_extents
70 allocated is less than would be required to map the requested range,
71 the maximum number of extents that can be mapped in the fm_extent[]
73 fm_extent_count. In that case, the last extent in the array will not
74 complete the requested range and will not have the FIEMAP_EXTENT_LAST
75 flag set (see the next section on extent flags).
81 __u64 fe_logical; /* logical offset in bytes for the start of
82 * the extent */
83 __u64 fe_physical; /* physical offset in bytes for the start
84 * of the extent */
85 __u64 fe_length; /* length in bytes for the extent */
92 for an extents logical offset to start before the request or its logical
93 length to extend past the request. Unless FIEMAP_EXTENT_NOT_ALIGNED is
94 returned, fe_logical, fe_physical, and fe_length will be aligned to the
95 block size of the file system. With the exception of extents flagged as
98 The fe_flags field contains flags which describe the extent returned.
99 A special flag, FIEMAP_EXTENT_LAST is always set on the last extent in
100 the file so that the process making fiemap calls can determine when no
101 more extents are available, without having to call the ioctl again.
103 Some flags are intentionally vague and will always be set in the
110 for inline or tail-packed data can key on the specific flag. Software
114 data. Note that the opposite is not true - it would be valid for
118 This is the last extent in the file. A mapping attempt past this
123 the data is stored on an inaccessible volume or that no storage has
124 been allocated for the file yet.
133 encoded (e.g. encrypted or compressed). Reading the data in this
134 extent via I/O to the block device will have undefined results.
136 Note that it is *always* undefined to try to update the data
137 in-place by writing to the indicated location without the
138 assistance of the filesystem, or to access the data using the
139 information returned by the FIEMAP interface while the filesystem
140 is mounted. In other words, user applications may only read the
141 extent data via I/O to the block device while the filesystem is
142 unmounted, and then only if the FIEMAP_EXTENT_ENCODED flag is
143 clear; user applications must not try reading or writing to the
144 filesystem via the block device under any other circumstances.
148 The data in this extent has been encrypted by the file system.
162 Unwritten extent - the extent is allocated but its data has not been
163 initialized. This indicates the extent's data will be all zero if read
164 through the filesystem but the contents are undefined if read directly from
165 the device.
170 userspace would be highly inefficient, the kernel will try to merge most
188 ->fiemap is passed struct fiemap_extent_info which describes the
198 It is intended that the file system should not need to access any of this
203 Flag checking should be done at the beginning of the ->fiemap callback via the
209 set of fiemap flags which the fs understands should be passed via fs_flags. If
210 fiemap_check_flags finds invalid user flags, it will place the bad values in
211 fieinfo->fi_flags and return -EBADR. If the file system gets -EBADR, from
216 For each extent in the request range, the file system should call
217 the helper function, fiemap_fill_next_extent():
222 fiemap_fill_next_extent() will use the passed values to populate the
223 next free extent in the fm_extents array. 'General' extent flags will
224 automatically be set from specific flags on behalf of the calling file
225 system so that the userspace API is not broken.
227 fiemap_fill_next_extent() returns 0 on success, and 1 when the
229 while copying the extent to user memory, -EFAULT will be returned.