On Thu, Nov 03, 2011 at 03:48:15PM -0700, Tommi Virtanen wrote: > On Thu, Nov 3, 2011 at 14:45, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > One clarification here that came up in a conversation: the code quoted > was explicitly inside if (is_bdev), that is, it is only used when the > journal was on a raw block device. That should make a lot of the > metadata & block allocation irrelevant. > > We're still very interested in hearing what are the real world barrier > / write cache flush guarantees from all the syscalls; the > documentation doesn't guarantee much, even for fsync.. from fsync(2): > > If the underlying hard disk has write caching enabled, then the > data may not really be on > permanent storage when fsync() / fdatasync() return. It should make it to disk, but various filesystems have QOI issues and never flush a disk cache. This is different from sync_file_range, which is implemented entirely inside the VM and has no chance at all to flush the cache (or filesystem metadata). Note that a block device might also have metadata for block allocations to flush - a prominent example is the device mapper thin provisioning target just merged in Linus' tree that relies on flushes to commit its metadata. Another example is any kind of sparse VM image file when seen from the guest. In both cases the metadata obviously hides behind the concept of cache flushes and isn't directly visible. -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
