Zdenek Kabelac [Mon, 1 Nov 2010 14:17:35 +0000 (14:17 +0000)]
Use new status code from fsadm check
Patch updates exec_cmd() and adds 3rd parameter with pointer for
status value, so caller might examine returned status code.
If the passed pointer is NULL, behavior is unmodified.
Patch allows to confinue with lvresize if the failure from fsadm check is
caused by mounted filesystem as many of filesystem resize tools do support
online filesystem resize. (originally user had to use flag '-n' to bypass
this filesystem check)
Peter Rajnoha [Mon, 1 Nov 2010 13:31:55 +0000 (13:31 +0000)]
Allocate buffer for reporting functions dynamically to support long outputs.
Fix memory leak of field_id in _output_field function.
There's been a patch added recently to use dynamic allocation for metadata
tags buffer to remove the 4k limit (for writing metadata out). However, when
using reporting commands like vgs and lvs, we still need to fix libdm reporting
functions themselves to support such long outputs. So the buffer used in those
reporting functions is dynamic now.
The patch also includes a fix for field_id memory leak which was found in
the _output_field function.
Alasdair Kergon [Fri, 29 Oct 2010 21:15:23 +0000 (21:15 +0000)]
Update VG metadata only once in vgchange when making multiple changes.
Allow independent vgchange arguments to be used together.
(Still more inconsistencies to iron out here.)
Petr Rockai [Wed, 27 Oct 2010 11:40:14 +0000 (11:40 +0000)]
Alasdair correctly pointed out that if the two closes are concurrent (I haven't
checked, so they *might*), there is still a race possibility with the last
fix. This patch fixes that.
Petr Rockai [Wed, 27 Oct 2010 09:13:37 +0000 (09:13 +0000)]
Fix a double close in clvmd.
The management threads (main_loop, the socket thread) could close a single fd
twice in a row sometimes. At least one other thread can be running at the same
time as the threads doing the double close. That one running thread also
happens to do some IO (namely, open /proc/devices, read from it, close it). If
there was enough "demand" for the local socket, this could happen:
- a connection to clvmd is about to finish, let's say the fd is 13 (it often
happens to be in my test script, don't ask why)
- the local_sock thread calls close(13)
- the lvm thread calls open("/proc/devices"...) and gets 13
- the main_loop thread calls close(13) [OOPS!]
- new connection arrives, and is accept'd by a (new) local_sock thread
- the accept gives an fd of 13 (since it's the lowest free fd at this point)
- the lvm thread gets around to read from it's /proc/devices handle... 13,
again
- the lvm thread hangs forever trying to read from the socket instead of
/proc/devices
Signed-off-by: Petr Rockai <prockai@redhat.com> Reviewed-by: Milan Broz <mbroz@redhat.com>
Zdenek Kabelac [Tue, 26 Oct 2010 10:14:41 +0000 (10:14 +0000)]
Add missing return for NULL passed buffer
Function pull_stateo() checks for NULL 'buf' - but return for this error
path was missing. cmirror code never calls this function with NULL 'buf',
so this fix has no effect on current code base, but makes clang happier.
Zdenek Kabelac [Tue, 26 Oct 2010 09:57:03 +0000 (09:57 +0000)]
Hotfix usage of __builtin_unreachable()
It's quite new feature which is not supported by older compilers.
So until some better macros are introduced into LVM code - hotfix current
compilation problems and compile this code only for __clang__ defining compilers.
Dave Wysochanski [Mon, 25 Oct 2010 14:09:08 +0000 (14:09 +0000)]
Add lvm_lv_get_property() generic function to obtain value of any lv propert
Add a generic LV property function to lvm2app, similar to VG function.
Return lvm_property_value and require caller to check 'is_valid' flag
and lvm_errno() for API error.
Dave Wysochanski [Mon, 25 Oct 2010 14:08:55 +0000 (14:08 +0000)]
Add lvm_pv_get_property() generic function to obtain value of any pv property.
Add a generic PV property function to lvm2app, similar to VG function.
Return lvm_property_value and require caller to check 'is_valid' flag
before using the value. If 'is_valid' is not set, then lvm_errno()
should be used to obtain the specific error.
Add a generic VG property function to lvm2app. Call the internal library
vg_get_property() function. Strings are dup'd internally.
Rework lvm_vg_get_property to return lvm_property_value and require caller
to check 'is_valid' flag. If !is_valid, the caller can check lvm_errno()
for the specific error.
Create a 'get_property' function, local to lvm2app, that factors out
most of the common code that copies the components of lvm_property_type
into lvm_property_value. This allows for a 1-line function for each
of the generic property functions exported by lvm2app.
Zdenek Kabelac [Mon, 25 Oct 2010 12:57:00 +0000 (12:57 +0000)]
Fix potential NULL pointer dereference
Makes clang happier as it covers all code paths and avoids NULL pointer
dereference through the 'com' pointer (which is NULL by default static
initialisation).
Zdenek Kabelac [Mon, 25 Oct 2010 11:57:06 +0000 (11:57 +0000)]
Fix clang warning for ntohl(*((uint32_t *)buf))
We cast (char*) to (uint32_t*) that changes alignment requierements.
For our case the code has been correct as alloca() returns properly
aligned buffer, however this patch make it cleaner and more readable
and avoids warning generation.
Mike Snitzer [Sun, 24 Oct 2010 17:36:58 +0000 (17:36 +0000)]
Never scan a device which is using the error target
A merged snapshot's DM device is made to use the "error" target as part
of lvm's transaction to merge a snapshot. This snapshot merge use-case
aside, any device using the error target shouldn't be scanned.
Dave Wysochanski [Thu, 21 Oct 2010 14:49:43 +0000 (14:49 +0000)]
Rename fields in lvm_property_type.
Based on review comments, rename a few fields in lvm_property_type.
In particular, change 'is_writeable' to 'is_settable', which is
more intuitive to the intent of the bitfield (a 'set' function
exists for this field/property). Also, remove the char array
for 'id' - unnecessary as we can just use the string passed in
to do the strcmp. Finally rename the union members from n_val
to 'integer' and 's_val' to 'string'.
Petr Rockai [Wed, 20 Oct 2010 14:46:45 +0000 (14:46 +0000)]
Fix a deadlock in clvmd.
The signalling code (pthread_cond_signal/pthread_cond_wait) in the
pre_and_post_thread was using the wait mutex (see man pthread_cond_wait)
incorrectly, and this could cause clvmd to deadlock when timing was
right. Detailed explanation of the problem follows.
There is a single mutex around (L for Lock, U for Unlock), a signal (S) and a
wait (W). C for pthread_create. Time flows from left to right, each arrow is a
thread.
So first the "naive" scenario, with no mutex (PPT = pre_and_post_thread, MCT =
main clvmd thread; well actually the thread that does read_from_local_sock). I
will also use X, for a moment when MCT actually waits for something to happen
that PPT was supposed to do.
MCT -----C ------S--X-----S----X----------------------S------XXXXXXXXX
| everything OK up to this --> <-- point...
PPT -----WWW-----WWWW------------------------------WWWWWWWWWWWWW
Ok, so pthread API actually does not let you use W/S like that. It goes out of
its way to tell you that you need a mutex to protect the W so that the above
cannot happen. *But* if you are creative and just lock around the W's and S's,
this happens:
Ooops. Nothing changed (the above is what actually was done by clvmd before
this satch). So let's do it differently, holding L locked *all* the time in
PPT, unless we are actually in W (this is something that the pthread API does
itself, see the man page).
MCT ----C-----LSU------X---LSU---X-----LLLLLLLSU----X----
| (and they live happily ever after)
PPT L---WWWWW---------WWWW----------------W----------
So W actually ensures that L is unlocked *atomically* together with entering
the wait. That means that unless PPT is actually waiting, it cannot be
signalled by MCT. So if MCT happens to signal it too soon (it wasn't waiting
yet), it (MCT) will be blocked on the mutex (L), until PPT is actually ready to
do something.
Petr Rockai [Fri, 15 Oct 2010 16:28:14 +0000 (16:28 +0000)]
Implement automatic snapshot extension with dmeventd, and add two new options
to lvm.conf in the activation section: 'snapshot_autoextend_threshold' and
'snapshot_autoextend_percent', that define how to handle automatic snapshot
extension. The former defines when the snapshot should be extended: when its
space usage exceeds this many percent. The latter defines how much extra space
should be allocated for the snapshot, in percent of its current size.
Fix for bug 637936: killing both redundant logs causes deadlock
Problem:
When both legs of a mirrored log fail, neither the log nor the parent
mirror can proceed. The repair code must be careful to replace the
log with an error target before operating on the parent - otherwise,
the parent can get stuck trying to suspend because it can't push through
any writes. The steps to replace the log device with an error target
were incomplete and resulted in the replacement not happening at all!
The code originally had all the necessary logic to complete the
replacement task, but was pulled out in a effort to clean-up that
section of code, while fixing another bug:
<offending commit msg>
In addition, I added following three changes.
- Removed tmp_orphan_lvs handling procedure
It seems that _delete_lv() can handle detached_log_lv properly
without adding mirror legs in mirrored log to tmp_orphan_lvs.
Therefore, I removed the procedure.
- Removed vg_write()/vg_commit()
Metadata is saved by vg_write()/vg_commit() just after detached_log_lv
is handled. Therefore, I removed vg_write()/vg_commit().
</offending commit msg>
Mike Snitzer [Wed, 13 Oct 2010 21:26:37 +0000 (21:26 +0000)]
Convey need for snapshot-merge target in lvconvert error message and man
page.
Add ->target_name to segtype_handler to allow a more specific target
name to be returned based on the state of the segment.
Result of trying to merge a snapshot using a kernel that doesn't have
the snapshot-merge target:
Before:
# lvconvert --merge vg/snap
Can't expand LV lv: snapshot target support missing from kernel?
Failed to suspend origin lv
After:
# lvconvert --merge vg/snap
Can't process LV lv: snapshot-merge target support missing from kernel?
Failed to suspend origin lv
Unable to merge LV "snap" into it's origin.
Zdenek Kabelac [Wed, 13 Oct 2010 12:18:53 +0000 (12:18 +0000)]
Don't use floor() in _bitset_with_random_bits
Use _even_rand() function instead of floor() in _bitset_with_random_bits().
floor() function is missing in dietlibc (on architectures other than x86).
Moreover using floor() to clip rand results does not assure even result
distribution. _even_rand() uses integer arithmetic only and is designed to
return evenly distributed results.
> Looks OK to me. It took a while to decipher what is the exact meaning of
> the loop in _even_rand (to a non-pseudorandomness-expert) but I am
> fairly comfortable with it now. If I understand this correctly, it
> rejects numbers that come from an "incomplete" slice of the RAND_MAX
> space (considering the number space [0, RAND_MAX] is divided into some
> "max"-sized slices and at most a single smaller slice, between [n*max,
> RAND_MAX] for suitable n -- numbers from this last slice are discarded
> because they could distort the distribution in favour of smaller
> numbers).
Petr Rockai [Wed, 13 Oct 2010 10:34:31 +0000 (10:34 +0000)]
Implement vgextend --restoremissing (BZ 537913), which makes it possible to
re-add a physical volume that has gone missing previously, due to a transient
device failure, without re-initialising it.
Signed-off-by: Petr Rockai <prockai@redhat.com> Reviewed-by: Alasdair Kergon <agk@redhat.com>