4 ms·
I don’t know of a better tool that operates on raw blocks, maybe there is one. `dd` is a real power user command, I’d prefer that it isn’t doing “intelligent”
by dijit 11d ago
I don’t know of a better tool that operates on raw blocks, maybe there is one.
`dd` is a real power user command, I’d prefer that it isn’t doing “intelligent” things, especially not by default.
- akdev1l 11d agocp file.iso /dev/sda
- ewy1 11d agothis works great but in my experience sometimes you should add && sync not sure why it's necessary only sometimes!
- rascul 11d agoThe kernel has a cache used for block devices. If you want to be more targeted: blockdev --flushbufs /dev/sda
- WhyNotHugo 11d agoThis isn't portable though, it's a GNU-specific "smart" things. Elsewhere, this overwrites the target device file.
- jasomill 11d agoRedirection doesn't overwrite device files, so cat foo.img > /dev/sda works and should be portable. No control over the buffer size, though.
- LtWorf 10d agoAnd no printing of progress either.
- akdev1l 11d agoHow exactly is cp not portable? Whatever behaviour you’re describing is not how POSIX mandates cp to work. In fact you can do this with busybox too. cp will open("/dev/sda", O_WRONLY | O_TRUNC) and simply start writing to that file descriptor.
- deleted 11d ago[deleted]
- dale_glass 11d agoHow about bmaptool? It can work on sparse images. In general, I don't see the point in manually specifying block sizes most of the time. What I want nearly always the maximum performance, and that should be possible to derive from the hardware, and/or benchmarking. What about uses like say, skipping data? seek= and skip= are in block sizes, that may not be ideal for performance. A smart tool should be able to write in 1 MB blocks and yet still skip 512 bytes.