Hi On Mon, Jun 10, 2013 at 1:22 AM, Thomas Bächler <thomas@xxxxxxxxxxxxx>wrote: > 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 > region > > 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. > > > 3) 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.