New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How is this faster than dd? #3825
Comments
For reference this is how I would to the same task using sudo dd if=image.wic of=/dev/sda status=progress conv=fsync |
Interestingly enough, the reported transfer speed at the end is 38 MB/s, which is almost exactly what etcher reports (it reports 41MB/s), but the |
Excellent question! So, file systems are stored in "blocks", and whenever the file system needs some space for a file, it allocates a new block. But up until that point, the block is just sitting there idle, with "garbage" data (the data might be old or just zeroes if it's a new disk). Even disk images straight from the creator will have "holes" (or unallocated blocks) in the disk image, and the only way to tell which blocks actually contain real data is by "asking" the file system.
The codebase is rather complex and difficult to understand, but all the "magic" happens in How exactly all of this works is rather complicated, so much so that I made a video explanation for internal use, but you're welcome to check it out if you're interested. This might sound self-serving, but the easiest way to understand it is usually to contribute to it, so PR's welcome :) |
Wow! Thanks for the detailed explanation! I'll definitely consider contributing! |
On the contrary I might ask why etcher is slower than usbimager writing compressed images?
Writing a 32G compressed image to the device takes half an hour in USBImager, and one and a quater hour (!) in etcher. 🚮 |
Looking at the table you linked to, the raw (uncompressed) write time is fairly similar, so I guess the difference is because Javascript is much slower at decompressing a bzip2 file than a native C application? 🤷 |
From the same source (which is a competitor, so I guess they picked their test image to look good): flashing a Raw image is faster with etcher... Is etcher the best/fastest for all cases? Probably not, but it's not its main purpose. The main question was a comparison with DD, so this is off-topic anyway. |
I can't wrap my head around how this tool is faster than plain old dd. The blocker for dd isn't even doing the copying, it's just waiting for dirty bits to flush to disk, an operation that etcher shouldn't even have any influence over. What's the magic bullet?
The text was updated successfully, but these errors were encountered: