В Пнд, 15/09/2008 в 23:38 +0200, Lars Marowsky-Bree пишет: > On 2008-09-15T18:14:45, Pan'ko Alexandr <[EMAIL PROTECTED]> wrote: > > > > 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'm not defending anything. I'm explaining. I hope. ;-)
Thank you. Thank you for your patient answer. > > 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. > > I did. I don't see this behaviour. After dd has returned and fsync() > completed, the file is on the peer too. > > Are you using drbd with protocol C? Yes. Protocol C. I not cleanly explained my actions. I pressed Ctrl-C before dd complete. That is why I get different sizes of files. On other peer it was even bigger :). It was because of previous test. > > Or you are saying that after each _byte_ writing I need do fsync() call? > > I modeling the accident in active write process. > > Applications use fsync() at strategic points in the data flow to ensure > transactional integrity. If the app would need that after every byte, > that would be a badly designed application. > > (Usually, applications do that before confirming something to the user, > same as one would use "commit" with a database transaction.) Yes. I am sorry. I was expected from network RAID the functionality better than in real hard drives... Now I understand that it is a deal of application to fix problems with system failures. > When you break the connection during replication and with on-going > writes, there'll always be some data missing on the other side. That > is > _not_ harmful, as the writes have not yet been confirmed to the > application either; it's the same with the various caches the data > passes through. Thank you, Lars! -- 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
