On Mon, Jun 10, 2013 at 1:22 AM, Thomas Bächler email@example.com:
Am 10.06.2013 05:18, schrieb Anatol Pomozov:
"sync" is not a workaround, it is a right solution.
You are wrong.
Under the hood copying in linux works following way. Every time you read something from disk the file information will stay cached in memory
called "buffer cache".
That is true - on a mounted file system. Writing directly to a block device (like /dev/sdb) does not use the buffer cache in any way.
Raw device access *does* use buffer cache. You can easily check it by watching writeback trace events:
# Create a loop block device dd if=/dev/zero of=afile bs=1M count=1000 sudo losetup /dev/loop0 ./afile
# enable writeback trace kernel events sudo echo 1 > /sys/kernel/debug/tracing/events/writeback/enable sudo echo 1 > /sys/kernel/debug/tracing/tracing_on # watch writeback events only for loop0 (7:0 is its major:minor) grep "7:0" /sys/kernel/debug/tracing/trace_pipe
# Now perform raw block device write and watch for writeback events sudo dd if=/dev/zero of=/dev/loop0 bs=1K
What you meant is "direct I/O" - in case of direct I/O operation bypasses buffer cache. So if you run
sudo dd if=/dev/zero of=/dev/loop0 bs=1K oflag=direct
you will not see writeback events as expected.
But direct I/O is orthogonal to raw block device access.
- Call "dd" operation with "conv=fsync" flag, this tells that dd should
not return until all data is written to the device.
Again, fsync only affects files on a mounted file system, not raw block devices.