Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
В Пнд, 15/09/2008 в 12:09 -0400, Greg Freemyer пишет: > 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 Thank you, Greg! It's very clean and understandable explanation. I even think it is worth to add to FAQ or HOWTO. Tank you again! -- Regards, Alexandr A. Panko