You may want to excercise your I/O subsystem.
Given that you probably don't want to stomp on a live filesystem, you
might want to create a file of a couple of gigabytes and turn it into
a pseudo-device with
'lofs(1)'.
EG:
# make a 15GB test file
dd if=/dev/zero of=the_testfile bs=1M count=15000
In using drbd 8.0.5 recently, I have come across at least two
instances where a bit on disk apparently flipped spontaneously in the
ext3 metadata on volumes running on top of drbd.
Also, I have been seeing regular corruption of a mysql database,
which runs on top of drbd, and when I reported
On Sep 17, 2007 13:31 -0400, Maurice Volaski wrote:
In using drbd 8.0.5 recently, I have come across at least two
instances where a bit on disk apparently flipped spontaneously in the
ext3 metadata on volumes running on top of drbd.
Also, I have been seeing regular corruption of a mysql
Hi Maurice,
If you're running into corruption both in ext3 metadata and in MySQL
data, it is certainly not he fault of MySQL as you're likely aware.
There are absolutely many places where corruption could occur between
MySQL and the physical bits on disk. The corruption you're seeing does
Hi Maurice,
Do you mean a Serially-Attached SCSI aka SAS controller, I assume?
Is this a custom build machine or a vendor integrated one?
Regards,
Jeremy
Maurice Volaski wrote:
On Sep 17, 2007 13:31 -0400, Maurice Volaski wrote:
In using drbd 8.0.5 recently, I have come across at least
Hi Maurice,
If you're running into corruption both in ext3 metadata and in MySQL
data, it is certainly not he fault of MySQL as you're likely aware.
I am hoping they are not related. The problems with MySQL surfaced
almost immediately after upgrading to 5.0.x.
[details deleted]
You can
Hi Maurice,
If you're running into corruption both in ext3 metadata and in MySQL
data, it is certainly not he fault of MySQL as you're likely aware.
I am hoping they are not related. The problems with MySQL surfaced
almost immediately after upgrading to 5.0.x.
It's possible that they are
