do ioctl(BLKDISCARD) in copy_raw_image_to_dev

[Villemoes]

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.

[jluebbe]

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.

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.

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.

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).

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.

Yes, this is better done transparently in RAUC.

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.

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.

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.

Yes, this would need to be opt-in per slot in the system.conf. lsblk -D is able to show the discard capabilities, so we could do the same during start-up and print a warning if a device supports discard but it's not configured for the slot.