shaba/lvm2
1
0
Fork 0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-22 17:35:59 +03:00
Code Releases Activity
6422b9ddc5
lvm2/libdm/.exported_symbols.DM_1_02_138

10 lines
234 B
Plaintext
Raw Normal View History

libdm: add dm_bit_get_last()/dm_bit_get_prev() It is sometimes convenient to iterate over the set bits in a dm bitset in reverse order (from the highest set bit toward zero), or to quickly find the last set bit. Add dm_bit_get_last() and dm_bit_get_prev(), mirroring the existing dm_bit_get_first() and dm_bit_get_next(). dm_bit_get_prev() uses __builtin_clz when available to efficiently test the bitset in reverse.
2016-12-11 15:44:45 +03:00
dm_bit_get_last
dm_bit_get_prev
daemons: add dmfilemapd Add a daemon that can be launched to monitor a group of regions corresponding to the extents of a file, and to update the regions as the file's allocation changes. The daemon is intended to be started from a library interface, but can also be run from the command line: dmfilemapd <fd> <group_id> <path> <mode> [<foreground>[<log_level>]] Where fd is a file descriptor open on the mapped file, group_id is the group identifier of the mapped group and mode is either "inode" or "path". E.g.: # dmfilemapd 3 0 vm.img inode 1 3 3<vm.img ... If foreground is non-zero, the daemon will not fork to run in the background. If verbose is non-zero, libdm and daemon log messages will be printed. It is possible for the group identifier to change when regions are re-mapped: this occurs when the group leader is deleted (regroup=1 in dm_stats_update_regions_from_fd()), and another region is created before the daemon has a chance to recreate the leader region. The operation is inherently racey since there is currently no way to atomically move or resize a dm_stats region while retaining its region_id. Detect this condition and update the group_id value stored in the filemap monitor. A function is also provided in the the stats API to launch the filemap monitoring daemon: int dm_stats_start_filemapd(int fd, uint64_t group_id, const char *path, dm_filemapd_mode_t mode, unsigned foreground, unsigned verbose); This carries out the first fork and execs dmfilemapd with the arguments specified. A dm_filemapd_mode_t value is specified by the mode argument: either DM_FILEMAPD_FOLLOW_INODE, or DM_FILEMAPD_FOLLOW_PATH. A helper function, dm_filemapd_mode_from_string(), is provided to parse a string containing a valid mode name into the appropriate dm_filemapd_mode_t value.
2016-12-15 23:10:27 +03:00
dm_filemapd_mode_from_string
libdm: add dm_stats_update_regions_from_fd() Add a call to update the regions corresponding to a file mapped group of regions. The regions to be updated must be grouped, to allow us to correctly identify extents that have been deallocated since the map was created. Tables are built of the file extents, and the extents currently mapped to dmstats regions: if a region no longer has a matching file extent, it is deleted, and new regions are created for any file extents without a matching region. The FIEMAP call returns extents that are currently in-memory (or journaled) and awaiting allocation in the file system. These have the FIEMAP_EXTENT_UNKNOWN | FIEMAP_EXTENT_DELALLOC flag bits set in the fe_flags field - these extents are skipped until they have a known disk location. Since it is possile for the 0th extent of the file to have been deallocated this must also handle the possible deletion and re-creation of the group leader: if no other region allocation is taking place the group identifier will not change.
2016-12-11 15:53:04 +03:00
dm_stats_update_regions_from_fd
libdm: add min_num_bits to dm_bitset_parse_list() It's useful to be able to specify a minimum number of bits for a new bitmap parsed from a list, for e.g. to allow for expansing a group without needing to copy/reallocate the bitmap. Add a backwards compatible symbol for programs linked against old versions of the library.
2016-12-12 01:41:45 +03:00
dm_bitset_parse_list
libdm: add dm_stats_bind_from_fd() dmsetup already has a version of this function, and dmfilemapd will need it too: move it to libdevmapper to avoid copying it around.
2016-12-18 17:40:57 +03:00
dm_stats_bind_from_fd
daemons: add dmfilemapd Add a daemon that can be launched to monitor a group of regions corresponding to the extents of a file, and to update the regions as the file's allocation changes. The daemon is intended to be started from a library interface, but can also be run from the command line: dmfilemapd <fd> <group_id> <path> <mode> [<foreground>[<log_level>]] Where fd is a file descriptor open on the mapped file, group_id is the group identifier of the mapped group and mode is either "inode" or "path". E.g.: # dmfilemapd 3 0 vm.img inode 1 3 3<vm.img ... If foreground is non-zero, the daemon will not fork to run in the background. If verbose is non-zero, libdm and daemon log messages will be printed. It is possible for the group identifier to change when regions are re-mapped: this occurs when the group leader is deleted (regroup=1 in dm_stats_update_regions_from_fd()), and another region is created before the daemon has a chance to recreate the leader region. The operation is inherently racey since there is currently no way to atomically move or resize a dm_stats region while retaining its region_id. Detect this condition and update the group_id value stored in the filemap monitor. A function is also provided in the the stats API to launch the filemap monitoring daemon: int dm_stats_start_filemapd(int fd, uint64_t group_id, const char *path, dm_filemapd_mode_t mode, unsigned foreground, unsigned verbose); This carries out the first fork and execs dmfilemapd with the arguments specified. A dm_filemapd_mode_t value is specified by the mode argument: either DM_FILEMAPD_FOLLOW_INODE, or DM_FILEMAPD_FOLLOW_PATH. A helper function, dm_filemapd_mode_from_string(), is provided to parse a string containing a valid mode name into the appropriate dm_filemapd_mode_t value.
2016-12-15 23:10:27 +03:00
dm_stats_start_filemapd
lvconvert: libdm RAID API compatibility versioning Commit 27384c52cf6a lowered the maximum number of devices back to 64 for compatibility. Because more members have been added to the API in 'struct dm_tree_node_raid_params *', we have to version the public libdm RAID API to not break any existing users. Changes: - keep the previous 'struct dm_tree_node_raid_params' and dm_tree_node_add_raid_target_with_params()/dm_tree_node_add_raid_target() in order to expose the already released public RAID API - introduce 'struct dm_tree_node_raid_params_v2' and additional functions dm_tree_node_add_raid_target_with_params_v2()/dm_tree_node_add_raid_target_v2() to be used by the new lvm2 lib reshape extentions With this new API, the bitfields for rebuild/writemostly legs in 'struct dm_tree_node_raid_params_v2' can be raised to 256 bits again (253 legs maximum supported in MD kernel). Mind that we can limit the maximum usable number via the DEFAULT_RAID{1}_MAX_IMAGES definition in defaults.h. Related: rhbz834579 Related: rhbz1191935 Related: rhbz1191978
2017-03-01 00:34:00 +03:00
dm_tree_node_add_raid_target_with_params_v2
libdm: maintain binary interface for new FEATURE flag Older library version was not detecting unknown 'feature' bits and could let start target without needed option. New versioned symbol now checks for supported feature bits. _Base version keeps accepting only previously known features and mask/ignores unknown bits. NB: if the older binary passed in 'random' bits, it will not get metadata2 by chance. New linked binary get new validation function. Library user is required to not pass 'trash' for unsupported bits, as such calls will be rejected.
2017-02-25 00:41:42 +03:00
dm_tree_node_add_cache_target
Copy Permalink