| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
Add a --nomonitor switch to disable spawning of dmfilemapd when
new file mapped groups are created.
|
| | |
|
| |
|
|
|
|
|
|
| |
Add a function to the stats API to launch the dmfilemapd filemap
monitoring daemon.
This carries out the first fork and execs dmfilemapd with the
appropriate arguments.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 interfface,
but can also be run from the command line:
dmfilemapd <fd> <group_id> <path> [<debug>[<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 1 3 3<vm.img
...
If debug is non-zero, the daemon will not fork into the
background. If verbose is non-zero, libdm and daemon log messages
will be printed.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The interface for dm_stats_update_regions_from_fd() states that
the handle will be listed on return:
* Following a call to dm_stats_update_regions_from_fd() the handle
* is guaranteed to be in a listed state, and to contain any region
* and group identifiers created by the operation.
Currently this only happens in the case that the regions need to
be re-grouped after the operation (i.e. the group leader was
deleted). Fix this to avoid a confusing state for cliend programs
where newly-created regions and group members are not reflected in
the handle.
|
| |
|
|
|
|
|
| |
Call _stats_regions_destroy() from dm_stats_list() if dms->regions
is non-NULL. This avoids leaking any pool allocations and ensures
the handle is in a known state: if an error occurs during the list,
dms->regions will be NULL and the handle will appear empty.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new update_filemap command to dmstats that allows a filemap
group to be updated:
# dmstats update_filemap --groupid 0 vm.img
/var/lib/libvirt/images/vm.img: Updated group ID 0 with 137 region(s).
This will update the set of regions mapped to the file to reflect
the current file system allocation.
Currently this needs to be run manually - a future update will add
support for monitoring file maps via a daemon, allowing them to be
automatically updated when the underlying file is modified.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a pair of helper functions for searching tables of _extent
objects:
/* test whether an extent matching start/len exists */
_extent_in_extents(nr_extents, extents, start, len)
/* return the extent matching star/len or NULL */
_find_extent(nr_extents, extents, start, len)
The filemap remapping support will use these when filtering the
set of extents that need to be updated in order to reflect the
current state of a mapped file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The dm_bit_copy() macro uses the source (bs1) bitset size as the
limit for memcpy:
memcpy((bs1) + 1, (bs2) + 1, ((*(bs1) / DM_BITS_PER_INT) + 1)..)
This is safe if the destination bitset is smaller than the source,
or if the two bitsets are of the same size.
With a destination that is larger (e.g. when resizing a bitmap to
add more capacity), the memcpy will overrun the source bitset and
set garbage bits in the destination.
There are nine uses of the macro currently (8 in libdm/regex, and
1 in daemons/cmirrord): in each case the two bitsets are always of
equal size so the behaviour is unchanged.
Fix the macro to use bs2's size to simplify resizing bitsets and
avoid the need for another copy macro.
|
| |
|
|
| |
Reuse existing code and some indent change.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 069039204002e5c8514050fe541bbd378c383a02 revealed a problem
in raid metadata manipulation.
We do two operations in one table reload:
- raid leg/image extraction
- rename remaining raid legs
This should be made in separate steps. Otherwise we do an
uncorrectable table change on error path (leaving tables
for admin and dmsetup).
As a hotfix - restore the previous logic and use a single
new function _lv_update_and_reload_list which activates exclusively
extracted LVs on the list before resuming suspended raid LV.
This restore 'rename' functionality upon resume.
Also still preserve the 'origin_only' logic - although we know
it's not working properly for cluster and LV stacking.
Further fixes are needed.
|
| |
|
|
|
| |
aclocal is regenerated while acinclude is permanent.
Move new macro to permanent file.
|
| |
|
|
|
|
|
|
|
| |
If FIEMAP returns a single extent after the first call, no extent
boundary is detected and the first extent is not counted by the
normal mechanism.
In this case, increment nr_extents at the same time the extent is
added to the region table, before returning.
|
| |
|
|
|
|
|
| |
backup is not 'tested' for success and also it should
actually happen just when command is finished.
We do not target to make backups with each inter-step
metadata change.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
RAID is LV property
TODO: only 2 flags are seg->status: PVMOVE & MERGING
At least the second one should be soon elimanted as again
we merge LV not a segment.
|
| |
|
|
| |
RAID is LV property - which has single segment of raid type.
|
| |
|
|
|
|
|
|
|
| |
This is another place for 'common' use pattern or
reload and activation of deleted devices.
(Moving the exclusive activation to _deactivate_and_remove_lvs()).
TODO: looks like halve of raid function is reloading
just 'origin' - and the other full LV.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Instead of iterating over all bits, use dm_bit_get_last() to find
the last set bit in the group bitmap.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Add a macro for the clz (count leading zeros) operation.
Use the GCC __builtin_clz() for clz() if it is available and fall
back to a shift based implementation on systems that do not set
HAVE___BUILTIN_CLZ.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Split out the loop that iterates over each batch of FIEMAP
extent data from the function that sets up and calls the ioctl
to reduce nesting and simplify local variable use:
_stats_get_extents_for_file()
-> _stats_map_extents()
The _stats_map_extents() function is responsible for detecting
eof and extent boundaries and adding whole, allocated extents
to the file extent table for region creation.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Check that all region_id values specified in a group bitmap are
actually present: although this should not normally happen when
using the dmstats tool, it is possible as a result of manual
changes (or bugs) for a group descriptor to contain one or more
group_id values that do not exist.
Check for this situation when reading group descriptors, warn
the user the user, and clear these bits in the bitmap when
formatting it for output.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a region has a a DMS_GROUP tag in aux_data where the first
region_id in the bitmap is not the same as the containing region,
dmstats will segfault:
# '2' is never a valid group bitset list for region_id == 0
# dmsetup message vg_hex/root 0 "@stats_set_aux 0 DMS_GROUP=img:2#"
# dmsetup message vg_hex/root 0 "@stats_list"
0: 45383680+16384 16384 dmstats DMS_GROUP=img:2#
1: 46071808+32768 32768 dmstats -
2: 47382528+16384 16384 dmstats -
# dmstats list
Segmentation fault (core dumped)
The crash will occur in some arbitrary dm_stats_get_* property
method - this happens while processing the 1st region_id in the
bitset, because the region is marked as grouped, but there is
no group bitmap present at dms->groups[2]->regions.
Fix this by detecting a mismatch between the expected region_id
and dm_bit_get_first() for the parsed bitset during
_parse_aux_data_group().
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Handle files that contain multiple logical extents in a single
physical extent properly:
- In FIEMAP terms a logical extent is a contiguous range of
sectors in the file's address space.
- One or more physically adjacent logical extents comprise a
physical extent: these are the disk areas that will be mapped
to regions.
- An extent boundary occurs when the start sector of extent
n+1 is not equal to (n.start + n.length).
This requires that we accumulate the length values of extents
returned by FIEMAP until a discontinuity is found (since each
struct fiemap_extent returned by FIEMAP only represents a single
logical extent, which may be contiguous with other logical
extents on-disk).
This avoids creating large numbers of regions for physically
adjacent (logical) extents and fixes the earlier behaviour which
would only map the first logical extent of the physical extent,
leaving gaps in the region table for these files.
|
| |
|
|
|
|
|
| |
Enhance commit 0b8bf73a63d8 to refresh the top-level LV correctly
in case of a clustered, remotely activated RaidLV.
Related: rhbz1399844
|
| |
|
|
| |
Default prepare_vg uses 512K - so update test accordingly
|
| | |
|
| | |
|
| |
|
|
| |
Avoid using signed int.
|
| |
|
|
|
| |
When test calls teardown, no devices created by test are expected
to be left in table. Trap such orphans and make the test fail.
|
| |
|
|
|
| |
Exit seemes slipped in from local testing in:
eb6b2a11e3548f7598c726787494be2c3ea4dca1
|
| |
|
|
|
|
|
| |
These tests leaks devices (known bugs).
Remove them via dmsetup.
TODO: fix actual commands
|
| |
|
|
|
|
|
| |
To be able to detect lvm2 command is not leaking some
'unexpected' device - remove all devices before
test exits by its own command so test teardown
now can check what was 'left' unexpectedly.
|
| |
|
|
| |
Some of test machines are too fast, slow raid syncing even more.
|
| | |
|
| | |
|
