4 ms·
> back in the day if you wrote to a block device with a write(2) size of anything other than a multiple of the devices actual block size you'd get a EIO or a EI
by mkup 10y ago
> back in the day if you wrote to a block device with a write(2) size of anything other than a multiple of the devices actual block size you'd get a EIO or a EINVAL
It's not back in the day, it's still true. In Linux, block devices are kernel-cached by default, unless opened with O_DIRECT flag.
In general UNIX case (for example, FreeBSD), they aren't:
https://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-block.html https://www.freebsd.org/doc/en/books/arch-handbook/driverbas...
So, in FreeBSD "dd bs=1" will fail if it involves any disk device: disk driver will return EINVAL from read(2) or write(2) because I/O size is not divisible by physical sector size. "cat" with buffer size X (which depends on implementation) will work or not depending on divisibility of X by physical sector size, and other random factors, like short file I/O caused by delivery of the signals.
Summary: dd(1) still has its place and author of original article is getting it wrong.
- tankenmate 10y agoYes you are right, there are some UNIXes that ship today without a buffer (block) cache and/or don't default to using the block cache when open(2)ing a block device. For those wondering Linux uses a unified buffer / page cache so there isn't a coherency issue. The buffer cache entries typically point to the corresponding entry in the page cache if it exists. The biggest reason the two are separate but correlated is that the block size isn't always the same as the page size.
- cat199 10y agocheers both - The raw/cooked device thing crossed my mind but thought it would distract from the point-by-point here..