Functions which provide data to a device special file are not an issue since this operates on a raw device driver and does not require filesystem overhead other than when determining if the user is allowed access. Any time your source data is from “/dev/zero” this is fulfilled. Any time your destination is to a partition instead of a file the requirement is fulfilled. Use something like “
gparted” to non-destructively slice part of your rootfs partition into a new partition. Then use dd with the output to that partition (device special file) instead of to a file.
Going through a file is not an error. I’ll compare this though to having an automobile race through the middle of a large city, and consider this to be a bad race car because it doesn’t run as fast as it does on a track designed for racing. Ext4 and some other filesystems may be relatively efficient, but this is far from streamlined. You could end up with the same results, but until you avoid the filesystem you are not testing the bandwidth of the raw device…you are testing the throughput of a series of devices chained together.
In the case of an error with a non-ext4 filesystem, this is quite possibly due to exceeding max file size for that filesystem type. Ext4 has an ability to work with enormous files, whereas some of the 32-bit Windows filesystem types stop at 2GB…if your filesystem is VFAT or FAT32 or one of those, then this will be an outright error forcing
dd to stop. Even if you do not fail under one of these other filesystem types I would expect ext4 to be better optimized and faster. Better yet is to not use a filesystem at all, and if you directly access a partition via the device special file, then no filesystem is in the chain (the filesystem is used to find the partition, but then stays out of the way).
You might end up with the same results, but if you pull the filesystem type out of the chain of limitations then you’ll actually know what you are profiling.