site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Jonas Maebe <jonas@zeus.ugent.be> wrote: Doesn't this behaviour also mean that the "safety" provided by journaling is basically not there? Or does the journaling code use HFS+ journaling does the same thing as F_FULLFSYNC to flush all data to disk. Actually to be correct, it is F_FULLFSYNC that asks the journal to do the work but the net effect is the same: we issue a DKIOCSYNCHRONIZECACHE ioctl on the underlying device and that in turn translates to the appropriate ATA, SCSI, or Fibre Channel command to ask the disk to flush its buffers to the media. And in case anyone is wondering: if you don't have journaling enabled then HFS+ just calls DKIOCYSNCHRONIZECACHE directly. These are implementation details that apps do not need to worry about. Out of curiousity, is there a benchmark I can run that shows this difference in performance between fsync being on and off? Just to be clear here: from the OS perspective there is no notion of fsync being "on" or "off" -- it always behaves the same way as documented in the man page. An system like SQlite may allow you to enable or disable calling fsync but that's a different thing altogether. At the OS level fsync is always "on". --dominic _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... If you were to use those platforms' functionality (where avaialble) to force a full push to disk, you would see similar performance regressions. howarth@bromo.msbb.uc.edu (Jack Howarth) wrote: This email sent to site_archiver@lists.apple.com