Searched full:metadata (Results 1 – 25 of 259) sorted by relevance
1234567891011
| /Documentation/networking/ |
| D | xdp-rx-metadata.rst | 4 XDP RX Metadata
8 hardware metadata related to a packet using a set of helper functions,
9 and how it can pass that metadata on to other consumers.
14 XDP has access to a set of kfuncs to manipulate the metadata in an XDP frame.
15 Every device driver that wishes to expose additional packet metadata can
20 metadata is supported, this set will grow:
31 An XDP program can use these kfuncs to read the metadata into stack
32 variables for its own consumption. Or, to pass the metadata on to other
33 consumers, an XDP program can store it into the metadata area carried
35 metadata available in which case the driver returns ``-ENODATA``.
[all …]
|
| D | xsk-tx-metadata.rst | 4 AF_XDP TX Metadata
8 via :doc:`af_xdp`. Refer to :doc:`xdp-rx-metadata` on how to access similar
9 metadata on the receive side.
14 The headroom for the metadata is reserved via ``tx_metadata_len`` and
15 ``XDP_UMEM_TX_METADATA_LEN`` flag in ``struct xdp_umem_reg``. The metadata
17 The metadata layout is a fixed UAPI, refer to ``union xsk_tx_metadata`` in
25 The headroom and the metadata itself should be located right before
26 ``xdp_desc->addr`` in the umem frame. Within a frame, the metadata
42 any metadata (i.e., the ones that don't have ``XDP_TX_METADATA`` option),
43 the metadata area is ignored by the kernel as well.
[all …]
|
| /Documentation/filesystems/xfs/ |
| D | xfs-self-describing-metadata.rst | 5 XFS Self Describing Metadata
17 Almost all metadata on XFS is dynamically allocated. The only fixed location
18 metadata is the allocation group headers (SB, AGF, AGFL and AGI), while all
19 other metadata structures need to be discovered by walking the filesystem
32 However, if we scale the filesystem up to 1PB, we now have 10x as much metadata
40 Self Describing Metadata
43 One of the problems with the current metadata format is that apart from the
44 magic number in the metadata block, we have no other way of identifying what it
46 you can't look at a single metadata block in isolation and say "yes, it is
50 verification of metadata values, looking for values that are in range (and hence
[all …]
|
| D | xfs-online-fsck-design.rst | 68 Metadata directly supporting these functions (e.g. files, directories, space
69 mappings) are sometimes called primary metadata.
70 Secondary metadata (e.g. reverse mapping and directory parent pointers) support
73 Summary metadata, as the name implies, condense information contained in
74 primary metadata for performance reasons.
76 The filesystem check (fsck) tool examines all the metadata in a filesystem
78 In addition to looking for obvious metadata corruptions, fsck also
79 cross-references different types of metadata records with each other to look
84 the filesystem metadata to a consistent state, not to maximize the data
91 More recent filesystem designs contain enough redundancy in their metadata that
[all …]
|
| /Documentation/userspace-api/media/v4l/ |
| D | dev-meta.rst | 6 Metadata Interface
9 Metadata refers to any non-image data that supplements video frames with
13 intended for transfer of metadata between the userspace and the hardware and
16 The metadata interface is implemented on video device nodes. The device can be
17 dedicated to metadata or can support both video and metadata as specified in its
23 Device nodes supporting the metadata capture interface set the
26 ioctl. That flag means the device can capture metadata to memory. Similarly,
27 device nodes supporting metadata output interface set the
30 metadata from memory.
38 The metadata device uses the :ref:`format` ioctls to select the capture format.
[all …]
|
| D | metafmt-generic.rst | 8 Generic line-based metadata formats
14 These generic line-based metadata formats define the memory layout of the data
15 without defining the format or meaning of the metadata itself.
22 The V4L2_META_FMT_GENERIC_8 format is a plain 8-bit metadata format. This format
25 Additionally it is used for 16 bits per Data Unit when two bytes of metadata are
30 Each cell is one byte. "M" denotes a byte of metadata.
34 .. flat-table:: Sample 4x2 Metadata Frame
55 V4L2_META_FMT_GENERIC_CSI2_10 contains 8-bit generic metadata packed in 10-bit
56 Data Units, with one padding byte after every four bytes of metadata. This
65 formats that pack two bytes of metadata into one Data Unit. Otherwise the
[all …]
|
| D | metafmt-d4xx.rst | 9 Intel D4xx UVC Cameras Metadata
15 Intel D4xx (D435, D455 and others) cameras include per-frame metadata in their UVC
17 means, that the private D4XX metadata, following the standard UVC header, is
19 proposed by Microsoft, and several proprietary ones. Supported standard metadata
22 document describes proprietary metadata types, used by D4xx cameras.
24 V4L2_META_FMT_D4XX buffers follow the metadata buffer layout of
31 Below are proprietary Microsoft style metadata types, used by D4xx cameras,
37 .. flat-table:: D4xx metadata
251 [9] LibRealSense SDK metadata source:
252 https://github.com/IntelRealSense/librealsense/blob/master/src/metadata.h
|
| D | metafmt-vivid.rst | 9 VIVID Metadata Format
15 This describes metadata format used by the vivid driver.
22 .. flat-table:: VIVID Metadata
|
| D | meta-formats.rst | 6 Metadata Formats
9 These formats are used for the :ref:`metadata` interface only.
|
| D | metafmt-uvc.rst | 15 This format describes standard UVC metadata, extracted from UVC packet headers
16 and provided by the UVC driver through metadata video nodes. That data includes
31 .. flat-table:: UVC Metadata Block
|
| /Documentation/admin-guide/device-mapper/ |
| D | era.rst | 21 era <metadata dev> <origin dev> <block size>
24 metadata dev fast device holding the persistent metadata
45 Create a clone of the metadata, to allow a userland process to read it.
50 Drop the metadata snapshot.
55 <metadata block size> <#used metadata blocks>/<#total metadata blocks>
56 <current era> <held metadata root | '-'>
59 metadata block size Fixed block size for each metadata block in
61 #used metadata blocks Number of metadata blocks used
62 #total metadata blocks Total number of metadata blocks
64 held metadata root The location, in blocks, of the metadata root
[all …]
|
| D | dm-zoned.rst | 27 internally for storing metadata and performing reclaim operations.
40 metadata. It can also use a regular block device together with the zoned
48 1) Metadata zones: these are conventional zones used to store metadata.
49 Metadata zones are not reported as usable capacity to the user.
60 device being used. This allows reducing the amount of metadata needed to
63 The on-disk metadata format is as follows:
66 super block which describes the on disk amount and position of metadata
114 Metadata Protection
117 To protect metadata against corruption in case of sudden power loss or
118 system crash, 2 sets of metadata zones are used. One set, the primary
[all …]
|
| D | thin-provisioning.rst | 24 Metadata is stored on a separate device from data, giving the
27 - Improve metadata resilience by storing metadata on a mirrored volume
30 - Improve performance by storing the metadata on SSD.
43 Userspace tools for checking and repairing the metadata have been fully
59 The pool device ties together the metadata volume and the data volume.
60 It maps I/O linearly to the data volume and updates the metadata via
71 Setting up a pool device requires a valid metadata device, and a
72 data device. If you do not have an existing metadata device you can
73 make one by zeroing the first 4k to indicate empty metadata.
77 The amount of metadata you need will vary according to how many blocks
[all …]
|
| D | dm-integrity.rst | 41 Accesses to the on-disk metadata area containing checksums (aka tags) are
42 buffered using dm-bufio. When an access to any given metadata area
43 occurs, each unique metadata area gets its own buffer(s). The buffer size
44 is capped at the size of the metadata area, but may be smaller, thereby
45 requiring multiple buffers to represent the full metadata area. A smaller
47 metadata area for small reads/writes. The metadata is still read even in
86 B - bitmap mode - data and metadata are written without any
88 regions where data and metadata don't match. This mode can
111 Don't interleave the data and metadata on the device. Use a
112 separate device for metadata.
[all …]
|
| D | cache.rst | 20 The target reuses the metadata library used in the thin-provisioning
56 3. A small metadata device - records which blocks are in the cache,
60 e.g. as a mirror for extra robustness. This metadata device may only
75 block sizes are bad because they increase the amount of metadata (both
86 the metadata.
131 Updating on-disk metadata
134 On-disk metadata is committed every time a FLUSH or FUA bio is written.
137 cache. If power is lost you may lose some recent writes. The metadata
181 cache <metadata dev> <cache dev> <origin dev> <block size>
186 metadata dev fast device holding the persistent metadata
[all …]
|
| D | dm-clone.rst | 29 The dm-clone target reuses the metadata library used by the thin-provisioning
58 3. A small metadata device - it records which regions are already valid in the
95 only updates its metadata.
124 Updating on-disk metadata
127 On-disk metadata is committed every time a FLUSH or FUA bio is written. If no
130 power is lost you may lose some recent writes. The metadata should always be
141 clone <metadata dev> <destination dev> <source dev> <region size>
145 metadata dev Fast device holding the persistent metadata
184 <metadata block size> <#used metadata blocks>/<#total metadata blocks>
187 <clone metadata mode>
[all …]
|
| D | persistent-data.rst | 8 The more-sophisticated device-mapper targets require complex metadata
21 framework for people who want to store metadata in device-mapper
53 On power failure your metadata will be as it was when last committed.
59 dm-space-map-metadata.[hc]
66 the metadata space. The latter is complicated by the need to store
|
| /Documentation/block/ |
| D | data-integrity.rst | 8 Modern filesystems feature checksumming of data and metadata to
18 support for appending integrity metadata to an I/O. The integrity
19 metadata (or protection information in SCSI terminology) includes a
40 allow the operating system to interact with the integrity metadata
46 information to each sector. The data + integrity metadata is stored
53 encouraged them to allow separation of the data and integrity metadata
67 when writing and vice versa. This allows the integrity metadata to be
73 buffers and the integrity metadata. These two distinct buffers must
76 The separation of the data and integrity metadata buffers as well as
108 the kernel) is concerned, the integrity metadata is opaque information
[all …]
|
| /Documentation/driver-api/dmaengine/ |
| D | client.rst | 167 **Optional: per descriptor metadata**
169 DMAengine provides two ways for metadata support.
173 The metadata buffer is allocated/provided by the client driver and it is
183 The metadata buffer is allocated/managed by the DMA driver. The client
185 the metadata and can directly update or read it.
187 Because the DMA driver manages the memory area containing the metadata,
191 metadata must not be accessed after issue_pending.
192 In other words: if the aim is to read back metadata after the transfer is
217 construct the metadata in the client's buffer
228 4. when the transfer is completed, the metadata should be available in the
[all …]
|
| D | provider.rst | 306 Per descriptor metadata support
308 Some data movement architecture (DMA controller and peripherals) uses metadata
310 payload and the metadata alongside.
311 The metadata itself is not used by the DMA engine itself, but it contains
314 The DMAengine framework provides a generic ways to facilitate the metadata for
321 The metadata buffer is allocated/provided by the client driver and it is
328 The data from the provided metadata buffer should be prepared for the DMA
334 On transfer completion the DMA driver must copy the metadata to the client
335 provided metadata buffer before notifying the client about the completion.
336 After the transfer completion, DMA drivers must not touch the metadata
[all …]
|
| /Documentation/filesystems/ext4/ |
| D | verity.rst | 11 metadata is filesystem-specific. On ext4, the verity metadata is
37 They can have EXT4_ENCRYPT_FL set, in which case the verity metadata
41 metadata.
|
| /Documentation/filesystems/ |
| D | squashfs.rst | 36 Metadata compression yes no
90 Only one block (data or metadata) can be
175 Metadata (inodes and directories) are compressed in 8Kbyte blocks. Each
180 Inodes are packed into the metadata blocks, and are not aligned to block
182 by a 48-bit number which encodes the location of the compressed metadata block
198 Like inodes, directories are packed into compressed metadata blocks, stored
206 compressed metadata block, and therefore, can share the start block.
216 in each metadata block. Directories are sorted in alphabetical order,
219 location of the metadata block the filename is in has been found.
220 The general idea of the index is to ensure only one metadata block needs to be
[all …]
|
| D | ceph.rst | 27 separates data and metadata management into independent server
28 clusters, similar to Lustre. Unlike Lustre, however, metadata and
36 Metadata servers effectively form a large, consistent, distributed
38 dynamically redistributes metadata in response to workload changes,
40 metadata server takes a somewhat unconventional approach to metadata
46 independent metadata servers, allowing scalable concurrent access.
177 cached metadata only when a lease or capability ensures it is
206 dirty data/metadata, invalidates page caches and writable file handles.
|
| /Documentation/core-api/ |
| D | assoc_array.rst | 20 Rather, the array is made up of metadata blocks that point to objects.
76 preallocated metadata blocks that will be installed in the internal tree and
77 keeps track of the metadata blocks that will be removed from the tree when the
340 can contain mixtures of leaves and metadata pointers.
353 constructed of two types of metadata blocks: nodes and shortcuts.
433 then the node will have all those leaves in it and will not have any metadata
436 A node can contain a heterogeneous mix of leaves and metadata pointers.
437 Metadata pointers must be in the slots that match their subdivisions of key
438 space. The leaves can be in any slot not occupied by a metadata pointer. It
440 metadata pointer. If the metadata pointer is there, any leaf whose key matches
[all …]
|
| /Documentation/networking/devlink/ |
| D | mlx5.rst | 85 - When applicable, disabling eswitch metadata can increase packet rate up
88 Eswitch port metadata state controls whether to internally tag packets
89 with metadata. Metadata tagging must be enabled for multi-port RoCE,
90 failover between representors and stacked devices. By default metadata is
91 enabled on the supported devices in E-switch. Metadata is applicable only
98 When metadata is disabled, the above use cases will fail to initialize if
102 must happen in legacy mode and eswitch port metadata takes effect after
|
1234567891011