Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 9/15/08, Pan'ko Alexandr <A.Panko at infocom.dn.ua> wrote: > В Пнд, 15/09/2008 в 16:11 +0200, Lars Ellenberg пишет: > > On Mon, Sep 15, 2008 at 04:43:49PM +0300, Pan'ko Alexandr wrote: > > > В Пнд, 15/09/2008 в 15:26 +0200, Lars Ellenberg пишет: > > > > > On Mon, Sep 15, 2008 at 03:55:55PM +0300, Pan'ko Alexandr wrote: > > > > > Hi. > > > > > > > > > > Let's see article from > > > > > http://wiki.centos.org/HowTos/Ha-Drbd > > > > > > > > > > > Let's do commands: > > > > > > > > > > [root at node1 /]# drbdadm primary repdata ; mount /dev/drbd0 /repdata > > > > > [root at node1 /]# dd if=/dev/urandom of=/repdata/test.file bs=1000000c > > > > > count=1000; ip l set eth0 down; > > > > > > > > > > > > > how about > > > > dd ... conv=fsync > > > > > > > > see also: man fsync > > > > > > Of cause I now about this params. > > > But are you sure that Tomcat and Firebird know about it too? :) > > > > that is _their_ problem. > > not drbd's. > > > > if it has never been submitted to drbd, > > drbd cannot replicate it. > > as simple as that. > > nothing drbd can do about it. > > DRBD _will_ work with them. > In case of no sync option it will be not reliable. > In case of sync option it _may_ work slowly. > It is all I want to confirm, because I do not see doc's and mails in > this list archive about such problem. > > I hope you do not mean that I must fsync() after _every byte_ wrote. > > > 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. > > > > > By such commands I modeling the accident fail of one of peer in active > > > disk writes. > > > > > > I know how to save files ;). > > > > good. > > then don't complain that drbd does not replicate file you did not save. > > It is live save. I act as normal program. > I did not say that "drbd does not replicate". > Drbd _does_ replicate but with no cache on ext3 filesystem. > > I changed dd on simple cp command (cp /tmp/1.file /; ip l set eth0 > down). And I do not see the file on other side at all. It is 73M length. > Moreover after I checked filesystem on other side - it says it is clean. > > DRBD is very good project I did not saying anything bad about it. > I simply give facts. Alexandr, I believe the issue is that you need to consider the robustness of your programs standalone prior to considering drbd's behavior. ie. What happens to the data your application is processing if you pull the power cord with no warning? Is the app robust enough to address this? For instance, a well written database uses ACID. (http://en.wikipedia.org/wiki/ACID) That ensures that when a system running a database stops unexpectedly and then is restarted, the database will be in a well known state. Simple utilities like dd and cp do not make any effort to ensure the robustness of their disk activities in the presence of system failures. Therefore drbd has no ability to function the way you desire. For tools that properly use commands like fsync to ensure robustness in the presence of system failure drbd should be a good solution. Your idea of using the sync mount option or calling fsync after every byte is a sledgehammer approach but even it will not work if the applications you want to use are not designed to work in the presence of system failures. ie. The app has 2 things it needs to update "atomically". They obviously happen sequentially in the real world, so what happens if the system fails between the first and second activity getting to disk. A well written application will have support code to address this. Simply calling fsync after every write does NOT do so. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com