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 something similar ?
no. Very strange, seeing as sync protocols should have nothing to do
with it.
Why is C slower than B in your setup?
:-\ As far as I understand our cluster uses special version of NFSV3
client code
that works like a "latency test" from the drbd point of view:
write everything in small fractions and commit it instantly.
Does your secondary have an
inferior I/O stack? I'd advise to match the peers' hardware and switch
Yes, peers have the same HW.
back to protocol C in that case. Otherwise, you should really try to
find out what's making it slow, because it shouldn't be.
Agree, but it is to be ensured that C protocol really solve the symptom and
not just hide it or just reduce the probability of it.
Cheers,
Felix
Akos
--
This communication is confidential and intended solely for the addressee(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If you
believe this message has been sent to you in error, please notify the sender by
replying to this transmission and delete the message without disclosing it.
Thank you.
E-mail including attachments is susceptible to data corruption, interception,
unauthorized amendment, tampering and viruses, and we only send and receive
emails on the basis that we are not liable for any such corruption,
interception, amendment, tampering or viruses or any consequences thereof.
Ericsson Magyarország Kft., Székhely: 1097 Budapest, Könyves Kálmán krt. 11. B.
épület. Nyilvántartó cégbíróság: Fõvárosi Bíróság. Cégjegyzékszám: 01-09-070937
_______________________________________________
drbd-user mailing list
[email protected]
http://lists.linbit.com/mailman/listinfo/drbd-user
