-
Notifications
You must be signed in to change notification settings - Fork 192
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
do ioctl(BLKDISCARD) in copy_raw_image_to_dev #1120
Comments
I've also thought about this feature some time ago, but didn't find time to implement it. Depending on the device, this can also make writing the image faster, as it might be able to skip read-modify-write cycles or avoid wear leveling.
Note that, when using tar images in RAUC, we create a new FS. Some mkfs implementations (such as ext4) will then use discard internally. For adaptive updates, we could discard any empty space after the image to the end of the partition (after the new data is written).
Yes, this is better done transparently in RAUC.
I've not seen SSD/eMMC devices where discard takes a significant amount of time compared to normal writes. So this might be a non-issue. Raw NAND or NOR erase operations take a long time, but that's not exposed as discard in Linux anyway.
Yes, this would need to be opt-in per slot in the system.conf. |
Is your feature request related to a problem? Please describe.
When we install a new squashfs image to a partition, if the new image happens to be (much) smaller than the old, the underlying block device has lots of unused blocks that might as well be scheduled for erasing and possibly put to use elsewhere.
Describe the solution you'd like
I think we should do ioctl(BLKDISCARD) on the whole partition in copy_raw_image_to_dev() before we start writing the data. We obviously cannot and should not do this earlier, i.e. not if adaptive updating is enabled.
Describe alternatives you've considered
I suppose this could be done in a pre-install hook, but it seems like the kind of thing that one could expect RAUC to handle transparently. And I suppose it's not really a problem with writable file systems that will be expanded to the full partition, since a periodic fstrim would then soonish deal with the unused blocks.
Additional context
The above assumes an eMMC with support for async erase. If the block device is not eMMC (say ordinary spinning rust), I don't know what BLKDISCARD would do. Also, we probably don't want to do the BLKDISCARD if it ends up synchronously waiting for the device to actually erase all the sectors. So perhaps this should be opt-in (via system.conf), or we should figure out if there's some way to detect that BLKDISCARD doesn't fall back to a sync erase.
The text was updated successfully, but these errors were encountered: