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. ;-)
> 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?
> > No. You should use proper test cases ;-)
> Give me a proper test command.
dd ... conv=fsync means that the file will be completely written on both
sides, onces dd returns.
> 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.)
> I repeated it with simple cp command.
> The results is the same.
No wonder, cp doesn't do any fsyncs either ...
> Coping with sync option on ext3 was extremely slow, but ok with sizes.
Of course. The sync option on mount enforces a sync after every write.
Not very efficient.
> Without sync option the file of 73M does not appear on other side at
> all. Moreover fsck says filesystem is clean.
Sure it's clean after the journal is replayed. That's what journaling
file systems are there for.
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.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
