You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
vbig --flush --progress /dev/usb-device for an 8 gigabyte device fills the disk block cache quickly, and then takes quite a while to flush out the buffer to the device. While the flushing is happening, there is no indication that something is happening in the terminal from which I launched vbig. If I didn't know what's happening, I would've assumed somethings broken.
This would've been acceptable without --progress.
Suggestion: show "flushing" if --progress is used, similar to the "writing" and "verifying" messages. Obviously "flushing" doesn't need to how much remains to flush, since that's difficult to get from the kernel.
Related suggestion: open the output file with O_DIRECT, when writing, at least on Linux, to avoid a lengthy flushing wait. Possibly O_SYNC.
The text was updated successfully, but these errors were encountered:
I've added a progress indicator but I'll keep this issue open for a while as a context for any further improvements.
Do you (or anyone) know of a way to get the kernel to report how much unwritten cached data is associated with a given file? (Doesn't have to be portable, I expect most users are on Linux anyway). Then we could have accurate progress reporting while keeping the (admittedly small) performance benefit of having the random number generation and the physical writes concurrent.
vbig --flush --progress /dev/usb-device
for an 8 gigabyte device fills the disk block cache quickly, and then takes quite a while to flush out the buffer to the device. While the flushing is happening, there is no indication that something is happening in the terminal from which I launched vbig. If I didn't know what's happening, I would've assumed somethings broken.This would've been acceptable without --progress.
Suggestion: show "flushing" if --progress is used, similar to the "writing" and "verifying" messages. Obviously "flushing" doesn't need to how much remains to flush, since that's difficult to get from the kernel.
Related suggestion: open the output file with O_DIRECT, when writing, at least on Linux, to avoid a lengthy flushing wait. Possibly O_SYNC.
The text was updated successfully, but these errors were encountered: