Hello,
I have a backup time degradation problem.
In a nutshell (it looks a write latency performance):
- the old IO pair ( SLES10 + drbd 8.2.6 ) can finish the task in 10 seconds
- the new IO pair ( SLES11SP2 + drbd 8.3.12 ) can do it in 16 seconds only.
I can force the old 8.2.6 configuration t
that 8.3.12 won't be compiled with 2.16.x kernel too
I hope we can find some kernel (or NFS or drbd) configuration option
that help a bit.
On 05/11/12 20:21, Zev Weiss wrote:
On May 10, 2012, at 11:00 AM, Csurai Akos wrote:
Hello,
I have a backup time degradation problem.
In a nutshel
Hi,
We have experienced a strange replication problem since we use B protocol.
The scenario is the following:
Some binary files are saved to the replicated IO pair ( kernel:3.0.13,
drbd-8.3.12, protocol B, EXT3 )
Later they are copied to an other (but replicated) directory.
They are still cons
On 08/01/12 10:22, Felix Frank wrote:
Hi,
On 08/01/2012 10:02 AM, Csurai Akos wrote:
Those corrupted binary files has some 40 kbytes hole filled with zeros.
Yes it can be a HW issue, but we did not see it with C protocol
(which is deadly slow in our system unfortunately)
Have someone seen
Hi,
What do I need to be able to access the tar.gz?
Forbidden
You don't have permission to access /drbd/8.4/drbd-8.4.2rc1.tar.gz on
this server.
Apache Server at oss.linbit.com Port 80
Thanks in advanced: Akos
p.s.
All the other tar.gz can be downloaded from : http://oss.linbit.com/drbd/
O
Hi,
Just an idea:
Last time when I see such a situation, someone suggested to print out
the env ... and there
I could see that the script was running in a wrong path. NFS was
temporary unavailable and that caused
the script "hanging"
Akos
On 08/13/12 23:34, J.R. Lillard wrote:
I have a three
Hi,
Just an idea:
Last time when I see such a situation, someone suggested to print out
the env ... and there
I could see that the script was running in a wrong path. NFS was
temporary unavailable and that caused
the script "hanging"
Akos
On 08/13/12 23:34, J.R. Lillard wrote:
I have a three
