| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
and how rescanning labels doesn't apply when reading
metadata from files.
|
| | |
|
| |
|
|
|
|
| |
A new aio context was being created, io_setup(2), in each
call to rescan labels. This is an expensive call, so keep
the aio context around to reuse in each call.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Now that label_read_data structs are used for both
sync and async reads.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
When label_scan reads metadata from independent areas, not
from the devices, set a flag on the vginfo. Use this flag
to avoid trying to rescan those devices in vg_read() since
the metadata won't be found on them, and wreck the lvmcache
data set up by the label scan.
|
| | |
|
| |
|
|
|
|
|
| |
duplicate PVs are detected during label scan and lvmetad
is disabled when they are detected. pvscan --cache can quit
after label scan if duplicates were found rather than going
through the remaining metadata reading steps.
|
| | |
|
| |
|
|
|
|
| |
We can read a large amount of data into label_read_data
synchronously also, and use this data in the processing path
instead of reading each bit of data from disk separately.
|
| | |
|
| |
|
|
|
|
| |
This command doesn't use process_each so it needs to
do a label_scan itself before trying to parse metadata,
which wants to know which PVs are on which devices.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is used to refresh the lvmetad content for a VG after
lvmlockd has invalidated the cached copy of the metadata in
lvmetad.
|
| |
|
|
|
|
|
|
|
| |
'pvscan --cache' for scanning all devices now uses
label_scan_async and can reuse data like other commands.
'pvscan --cache dev' can't do a label_scan because it's
only allowed to read the single dev. A label_read on
that single dev is added prior to reading the VG from it.
|
| |
|
|
|
|
| |
Use a separate alloc/free loop for ld structs from
mem pool vs the aio-related structs that are not
from pool.
|
| |
|
|
|
| |
Use the actual aio system calls only in dev-io.c
and use an obfuscation layer above that in lvm.
|
| |
|
|
|
|
|
|
|
|
|
| |
label_scan is a primary step that a command performs,
following the standard pattern for command processing.
It was being called as a side effect of a utility/helper
function, which made it less obvious and made it easier
to be called without realizing it. Pull it up to a
prominent top level in the sequence of primary steps.
label_scan is not something that should be done in
various low level places as needed.
|
| |
|
|
|
|
|
|
|
|
|
| |
when using async read data.
This is the short disk read that validates VG metadata
before reading the full metadata. There's a nearly
identical function in the label scan path, as this one
in the vg_read path. The other version was already
adapted to use the label read data, but this one was
missed.
|
| |
|
|
|
|
|
| |
Both for rescanning labels at the start of vg_read,
and then passing and using that reread data through
the vg_read() path to avoid rereading the same data
from disk.
|
| |
|
|
| |
comments added where future error path handling should go
|
| |
|
|
|
|
| |
Make the function names and messages parallel each other
on the two parallel vg reading paths (label reading and
vg_read).
|
| |
|
|
| |
This moves a low level label scan to the start of vg_read.
|
| |
|
|
|
|
|
|
|
|
|
| |
When vg_read() begins, it looks up the format (fmt) for
the VG name in lvmcache, telling lvmcache_fmt_from_vgname()
to reread labels on all devices in the VG.
Avoid rereading the labels on all the devices, and trust
that lvmcache has correct information. If the format of
the VG is not available, the calling code already
rescans labels and retries.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the low levels of vg_read() are parsing VG metadata,
they see a PVID, and try to get the device for it, calling
lvmcache_device_from_pvid(). When this function found
the dev for this PVID in lvmcache, it would issue a
full label_read() on that device and verify that the
pvid/dev mapping in lvmcache is correct.
Remove this label_read() and trust that the pvid to dev
mapping in lvmcache is correct. If metadata changed
between the initial label scan performed by the command,
and the locked vg_read(), then other code exists to
rescan labels.
(The lvmetad case already trusted the contents of lvmcache.)
|
| |
|
|
|
|
| |
Copy the metadata out of the initial async read buffer
instead of performing another two synchronous reads
(first to check vgname, second to read all metadata.)
|
| |
|
|
|
|
|
|
|
| |
Extend the initial async read buffer size to cover all
the headers/metadata that need to be read from the device
during label scan.
Copy the mda_header from this buffer instead of performing
another synchronous read for it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The copy of VG metadata stored in lvmcache was not being used
in general. It pretended to be a generic VG metadata cache,
but was not being used except for clvmd activation. There
it was used to avoid reading from disk while devices were
suspended, i.e. in resume.
This removes the code that attempted to make this look
like a generic metadata cache, and replaces with with
something narrowly targetted to what it's actually used for.
This is a way of passing the VG from suspend to resume in
clvmd. Since in the case of clvmd one caller can't simply
pass the same VG to both suspend and resume, suspend needs
to stash the VG somewhere that resume can grab it from.
(resume doesn't want to read it from disk since devices
are suspended.) The lvmcache vginfo struct is used as a
convenient place to stash the VG to pass it from suspend
to resume, even though it isn't related to the lvmcache
or vginfo. These suspended_vg* vginfo fields should
not be used or touched anywhere else, they are only to
be used for passing the VG data from suspend to resume
in clvmd. The VG data being passed between suspend and
resume is never modified, and will only exist in the
brief period between suspend and resume in clvmd.
suspend has both old (current) and new (precommitted)
copies of the VG metadata. It stashes both of these in
the vginfo prior to suspending devices. When vg_commit
is successful, it sets a flag in vginfo as before,
signaling the transition from old to new metadata.
resume grabs the VG stashed by suspend. If the vg_commit
happened, it grabs the new VG, and if the vg_commit didn't
happen it grabs the old VG. The VG is then used to resume
LVs.
This isolates clvmd-specific code and usage from the
normal lvm vg_read code, making the code simpler and
the behavior easier to verify.
Sequence of operations:
- lv_suspend() has both vg_old and vg_new
and stashes a copy of each onto the vginfo:
lvmcache_save_suspended_vg(vg_old);
lvmcache_save_suspended_vg(vg_new);
- vg_commit() happens, which causes all clvmd
instances to call lvmcache_commit_metadata(vg).
A flag is set in the vginfo indicating the
transition from the old to new VG:
vginfo->suspended_vg_committed = 1;
- lv_resume() needs either vg_old or vg_new
to use in resuming LVs. It doesn't want to
read the VG from disk since devices are
suspended, so it gets the VG stashed by
lv_suspend:
vg = lvmcache_get_suspended_vg(vgid);
If the vg_commit did not happen, suspended_vg_committed
will not be set, and in this case, lvmcache_get_suspended_vg()
will return the old VG instead of the new VG, and it will
resume LVs based on the old metadata.
|
| |
|
|
| |
Also remove some redundant function definitions from metadata.h.
|
| | |
|
| |
|
|
| |
Fixing name for RT libraries and using RT_LIBS.
|
| |
|
|
|
| |
When the sanlock daemon does not have permission to access
the lvmlock LV, make the error messages more helpful.
|
| |
|
|
|
|
|
|
| |
Replaced the confusing device error message "not found (or ignored by
filtering)" by either "not found" or "excluded by a filter".
(Later we should be able to say which filter.)
Left the the liblvm code paths alone.
|
| | |
|
| |
|
|
|
| |
Add missing monitoring for external origin LVs and add -real suffix
for UUID used for monitoring of external origin.
|
| | |
|
| |
|
|
|
| |
It has not been used in a long time and is not
expected to be used further.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Fixes the following case with 3PVs and 3 legs "mirror" LV:
# lvcreate -l100%FREE --type mirror -m2 vg3
Insufficient free space for log allocation for logical volume .
Unable to allocate extents for mirror log.
Related: rhbz1269533
|
| |
|
|
|
| |
...when running from ramdisk. This causes test failure, so it is kept on
eyes.
|
