If there are holes in the logfile sequence and this holes concern only logfiles
which are already applied (i.e. logfiles lying before all replay links)
the secondary can continue working.
Warnings are written as long as the situation exists.
Signed-off-by: Thomas Schoebel-Theuer <tst@1und1.de>
Up to now holes in the logfile sequence caused the copy process to stop after
having fetched the last logfile before the hole.
E.g. in emergency mode such holes are created intentionally on the primary
side. After the situation has been cleaned up, the secondary must be able to
fetch newly created logfiles.
Signed-off-by: Thomas Schoebel-Theuer <tst@1und1.de>
We report an error if there are unfreed mrefs after the device brick
has been switched to power off.
Instead of reporting an error at once, we report only warnings in the first 20
seconds. If there are still unfreed mrefs after that time an error is reported.
Signed-off-by: Thomas Schoebel-Theuer <tst@1und1.de>
Some filesystems like ext3 have only full second resolution.
Therefore, we _must_ advance the Lamport clock in whole seconds
when working on such gear, since we want to prevent lost
updates which would be caused by standstill Lamport clocks.
Sometimes, the lamport clock gets updated more frequently per second
than real time. In such cases, the Lamport clock will run much faster
than real time. After some weeks of operation, the Lamport clock
will be far in the future.
In general, we cannot do anything against that. When some fine-grained
information cannot be coded into some specific data type, it
cannot be coded.
However, when updates start to occur less frequently, we want to
_leave_ the workaround mode ASAP. The old code set tv_nsec to 0
which made it very likely that the workaround was triggered
again unnecessarily.
In order to _reduce_ that effect, we prevent unnecessary cascades
of whole-second leaps by setting the nanoseconds constantly to 1
if the full second was increased due to insufficient capabilities
of the underlying filesystem. At least in those cases where
Lamport timestamps are transferred over the network and/or we have
mixed configurations between ext3/ext4, we hope to
decrease the risk of endless cascades.
Experience shows that the new code behaves better.
Since commit 62e2f5944b, aio prevents races on the length
of a transaction logfile.
Thefore, we can safely enable IO parallelism at writes fired off
by copy.
The old behaviour was a serious IO bottleneck.
In case CONFIG_HIGH_RES_TIMERS is not set (or when it does not work
as expected), the lamport clock could "stop" in some extremely
rare cases. Theoretically, a symlink update could be missed, or
two transaction log records could accidentally get the same
timestamp. We want any timestamps to be unique (at least on
the same host).
This patch ensures that true forward stepping always takes place,
even when the system clock fails (or at other problems).
For now, the dependency from CONFIG_HIGH_RES_TIMERS is left in Kconfig
as a precondition for MARS.
After some tests and some observational time, it could probably be removed
some day.
This is needed for detection of the real end of inconsistencies
after sync as finished. Consistency is only (re-)reached after
a certain amount of logfile data has been sucessfully applied.
This patch remembers the replaylink from the primary at the time
when the sync has finished.
When at least that amount of logfile data has been applied, we
are certain that now we are consistent.
On the secondaries, switchover between logfiles could hang
when _check_logging_status() used the tolerance, but
is_switchover_possible() refused to switch over.
