-
Notifications
You must be signed in to change notification settings - Fork 167
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
File transfer is slow #1376
Comments
Because labgrid could at some point switch away the hardware from underneath the kernel, i.e. when using a USB SD mux or sd wire device. The write cache needs to be flushed either way, so my expectation would be that you'll have to wait for the cache to be flushed during a |
Thanks for the info If I understand this correctly, fdatasync should be enough for syncing - directio is not needed and just slows things down. If the hardware disappears while writing or before syncing, then the dd will fail either way. |
Perhaps the solution here is to use separate 'sync' after the dd? |
@sjg20 I suspect that would work; is it actually any faster to do it that way? |
Yes with rock2 u-boot-rockchip.bin (8898660 bytes) With my change: Image written in 5.7s I am using quite slow media. |
When writing large images (more than a few 100MiB, on hosts with just 1-2 GiB of RAM) without What's the Better approaches are definitely possible (perhaps |
That sounds like an edge case to me (low memory). I could make it use direct if the size is larger than 20MB, perhaps? $ lsblk -t /dev/sdk I do need skip and seek most of the time the two versions are: fast: slow: |
I notice that the fdatasync doesn't slow things down on the one case I am testing here (so we can use that instead of a separate 'sync'). It is the direct I/O that is the problem |
The current implementation is driven by the use-cases we know about, like our lab with hundreds of places split into 16 per exporter (PCEngines APU with 4GB RAM). Many of them use USB-SD-Muxes, writing 500MiB-2GiB images. Keeping the influence on tests running in parallel is critical there and drove the change you cited. That's far from an edge case. I'd be open to a driver-level attribute to disable oflag=direct, perhaps Do you get sensible progress output from dd without oflag=direct? Previously it would report high speeds until write-back starts and then hang a long time at the end, which was confusing to users. What sort of storage device are you using? |
Thanks for the background as to why this was done. This is using uSD cards. Re he driver-level attribute, would that need each board to put the attribute in its environment? Is there some overall setting that could be used? Using direct I/O seems to only be a win for large images on machines with not much memory. |
When writing an 8MB image to a board I see this:
The last bit seems to be the 'dd'.
If I drop the 'oflag=direct' from USBStorageDriver.write_image I get:
which is a bit better. Why is direct I/O needed?
This doesn't make a lot of sense to me. Why not let the kernel handle the caching?
The text was updated successfully, but these errors were encountered: