[arch-general] Super weird dd problem.

[Anatol Pomozov]

Hi

On Mon, Jun 10, 2013 at 1:22 AM, Thomas Bächler <thomas at archlinux.org>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.