В Пнд, 15/09/2008 в 16:41 +0200, Lars Marowsky-Bree пишет: > On 2008-09-15T17:06:08, Pan'ko Alexandr <[EMAIL PROTECTED]> wrote: > > > Let's do commands: > > > > [EMAIL PROTECTED] /]# drbdadm primary repdata ; mount /dev/drbd0 /repdata > > [EMAIL PROTECTED] /]# dd if=/dev/urandom of=/repdata/test.file bs=1000000c > > count=1000; ip l set eth0 down; > > [EMAIL PROTECTED] /]# ls -l /repdata/test.file > > -rw-r--r-- 1 user users 1000000000 Sep 15 15:07 /repdata/test.file > > There is no fsync() or fflush() call happening there. open/write/close > is not atomic, and may lag behind.
I do not understand what you are defending at all. I say about _NEED_ of use sync option if it is ext3 filesystem. If I cancel connection in progress of dd ... conv=fsync, I get the same results as with no conv=fsync. Please try yourself and only then write here. > That's not a drbd issue, but the kernel caches are simply not flushed. > > All applications which actually care about their data use fsync() > properly. The test case is not "valid" in that regard. > > > SHOULD I turn off caching om ALL underling devices and filesystems to > > get HA cluster filesystem? > > No. You should use proper test cases ;-) > Give me a proper test command. Or you are saying that after each _byte_ writing I need do fsync() call? I modeling the accident in active write process. I repeated it with simple cp command. The results is the same. Coping with sync option on ext3 was extremely slow, but ok with sizes. Without sync option the file of 73M does not appear on other side at all. Moreover fsck says filesystem is clean. -- Regards, Alexandr A. Panko _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
