5 ms·

> I don't know why dd remains the standard for so many tutorials While dd isn't the best tool for writing images to devices (if only because of its arcane and

• rzzzt 6y ago
  ddrescue can also help with that use case: https://www.gnu.org/software/ddrescue/ https://www.gnu.org/software/ddrescue/
  • lizknope 6y ago
    I always used ddrescue like this. Even on badly scratched discs it was able to recover most of the data. ddrescue -b 2048 -d -r 3 -R -v /dev/sr0 image.iso image.log
    • compsciphd 6y ago
      I used to use 2048, that's probably the wrong value to use. want to use something that corresponds to the ECC block size of the underlying media. but yes, I do that as well (came to say mostly the same comtent, but I'd do r -1)
      • colejohnson66 6y ago
        Is the ECC available to the OS? I thought the drive handled the ECC and just reported errors?
        • wtallis 6y ago
          If you're trying to read with a smaller block size than the media's native block size, then you'll make two or more attempts to read data from each corrupted block that's unrecoverable—making your recovery process much longer. If you try to read with a larger block size than the media's native block size, you'll get errors for chunks of that size even when part of the data may have been recoverable. The above is true whether or not the OS has access to the media's raw ECC data.
          • compsciphd 6y ago
            it's not just that. Reading scratched blocks means sometimes it might work, sometimes it might not. lets say 1% of the time you get a good read. If the ECC block is 16k and you always read in 16k blocks, if you get that 1% magic time that the read succeeds, you got the whole block. If however, you read 2k blocks, you need to have the same luck 8x times. From experience of recovering bad DVDs and BRs, there were discs I had to pass through 100+ times to get a valid read on all blocks. This is also because, the underlying hardware will always do a full ecc block read (only way for it to determine that it read the block correctly, to read whole block and verify it), so any smaller reads are pointless.
        • compsciphd 6y ago
          just in case you didn't read my response below, its not about the ECC being available to the OS, the OS doesn't need to see it. the way optical media works is that the optical media reads bits from the drive in ECC block size and then verifies / fixes the block and passes that back to the OS if its has a valid block, otherwise returns an error to the OS. hence, my logic that I describe below. optical media is an unreliable medium in general and hence depends on the ECC codes to ensure blocks are read correctly and they are used a lot. back in the day of CD and DVD burning there were fancier burners that provided apis for reading the error correcting stats into user space (i.e. how many of different types of errors were corrected), dont know if they still exist. It was never 0 across the board, but that's how the medium was designed, not to require it be 0 across the board.
          • colejohnson66 6y ago
            What I guess I don’t understand is: why does the OS need to know the internal ECC block size if it doesn’t even see the ECC (or even know of its existence)? When I want a sector from my hard drive, I ask for 4096 bytes, not 4096+$ECC.[0] If I asked for 4096+$ECC, it would actually give me 4096 from the sector I requested, and $ECC from the next one. So why ask for 2048+$ECC and not just 2048? As you said, the nature of the medium requires ECC (side note: modern hard drives do too). So if I ask for a 2048 byte sector, the drive has to read the ECC. So why ask for more than that? It already knows the sector boundaries. In other words, if I tell `dd` to use a block size of 2048+$ECC, won’t that actually work a sector and a half (well, 1 + $ECC/2048) at a time? [0]: In fact, unlike CDs, I don’t even know or have any way of finding out how many ECC “bytes” there are in my hard drives' sectors
            • compsciphd 6y ago
              because the OS did't cache the full ecc block (it views the block size as 2048 or 4096 bytes), and with scratched media 2 reads of the same ecc block aren't going to necessarily both succeed. simplistic case, imagine we have 1 ECC block of 16k, but we read at 2k, so we'll number the 2k blocks 0-7 T0 - read block 0, fails T1 - read block 1, succeeds! T2 - read block 2, fails T3-T7 repeat for blocks 3-7, all fail in practice if we read a 16k bock at T1, we would be golden (and finished). Instead we did 8 steps, and only got 1/8 of the data. This is becaue the OS doesn't have a concept of the hardware's ECC block size, so the optical hardware in a sense virtualizes it, and the OS will just keep on rereading the same ECC block on the media and possibly continue to get errors.
    • compsciphd 6y ago
      I'd also add that -R (reverse) doesn't make sense to me for optical media. really would slow down recovery as the default direction I'd think.
  • wtallis 6y ago
    It's been so long since I regularly used optical discs (for anything other than the rare rented DVD) that I now assume by default that I'll need ddrescue because the discs are all old.
• kukx 6y ago
  > arcane and bizarre command-line syntax It is not arcane, you just have to read docs, like for every command line tool. Different cli applications have different syntaxes usually influenced by their domains, eg compare find, tcpdump, iptables, cut, docker.
  • dTal 6y ago
    No, it is arcane and bizarre. No other command line tool uses dd's syntax.
    • hutzlibu 6y ago
      Example? I used dd a lot to burn images on USB. And that command is simple as expected.
      • dTal 6y ago
        I can't provide an example of something which doesn't exist, i.e. another program with dd's syntax. I didn't say it wasn't simple. But it is very weird.
        • moistbar 6y ago
          What's weird about a syntax as straightforward as 'command name' 'input file' 'output file'? How exactly would you do it differently?
          • remram 6y ago
            If it were `dd input output` or `dd input -o output` no one would be claiming it's unique and bizarre. However the actual syntax is `dd if=input of=output` which is unique and (arguably) bizarre.
            • moistbar 6y ago
              Unique, yes, and I'd even go as far as to say it's somewhat out of place on a Unix-like OS, but I have an easier time remembering "infile, outfile, block/batch size" than, say, arguments for tar due to its simplicity. I wouldn't call it bizarre because it's extremely straightforward.
• ryandrake 6y ago
  It’s also nearly guaranteed to be available on the user’s system. Are there other tools to do this? Yes, in fact too many, to the point where none of them are the clear leader. I hate tutorials that start out with “I’m gonna show you how to do X. I like to use Y, but since the Y tool isn’t installed, we have to get it. Start by editing sources.list. You might need to be root to do this. Here is how you do that.” Halfway through the tutorial we’re still Yak shaving.
• ornxka 6y ago
  >its arcane and bizarre command-line syntax I actually like dd's command-line syntax the most out of the Linux coreutils, and I wish more programs used a similar "key=value" argument system. It's pretty easy to remember too, since there's really only a few keys you need to remember to do 99% of what dd typically gets used for.