Hi Greg, On 02/13/2014 04:26 PM, Greg Freemyer wrote:
On Wed, Feb 12, 2014 at 8:03 AM, Bernhard Voelker <mail@bernhard-voelker.de> wrote: I don't know:
iflag=fullblock
What does that really do? I've never seen it recommended before for handling a drive with bad sectors.
Well spotted, we're discussing the same question upstreams. ;-) I'm not sure it is required for block devices, but however ... depending on the ibs size I could imagine that short reads cannot happen for block devices, too. AFAIK fullblock cannot do any harm.
I checked the man page, but it is uninformative.
The man page of coreutils is effectively the same as "dd --help". Use "info coreutils 'dd invocation'" or shorter "info dd" instead. `fullblock' Accumulate full blocks from input. The `read' system call may return early if a full block is not available. When that happens, continue calling `read' to fill the remainder of the block. This flag can be used only with `iflag'. This flag is useful with pipes for example as they may return short reads. In that case, this flag is needed to ensure that a `count=' argument is interpreted as a block count rather than a count of read operations. The (probably ugly) point is that POSIX requires short reads per default, so GNU dd(1) provides fullblock as an allowed extension to fit better into daily usage.
fyi: The above defaults to 512 byte blocks. That can be extremely inefficient with linux. The trouble is if you bump the blocksize up, dd will only partially fill the block with valid data, then 00 fill the rest of the block after the error.
Yes, true. That's why other tools with adaptive ibs size settings usually fit better ... well, that's what they are designed for. ;-) However, given the failing blocks on the disk are located on the disk where no or only unimportant data is stored, I would think that dd(1) could do a pretty good job. Furthermore, you don't have a learning curve if you are familiar with dd(1) ... and finally, it's available everywhere. My mail now also serves as a heads-up again to make 'fullblock' more known to the public ... and to avoid short read issues in other (pipe) cases. ;-) Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org