Hi Sean, Thanks for the feedback!
On Wed, Jun 03, 2026 at 01:43:10PM -0400, Sean Anderson wrote: > On 5/28/26 23:44, [email protected] wrote: > > From: Denis Mukhin <[email protected]> > > > > Introduce `flush` subcommand for all blk devices to allow committing > > dirty data explicitly to the given block device. > > Shouldn't this be done automatically as part of blk_write? Similar to > how all FS operations in U-Boot look like > > - Mount FS > - Perform operation > - Unmount FS > > so the FS is never in an inconsistent state once an operation completes. > > Is the performance impact too much? I'm just concerned that a lot of > existing code assumes that blk_write is persistent and that it's OK > to e.g. immediately reset after blk_write returns. In my case I need to update the GPT-backed boot counter; there are two GPT headers, primary and backup, so I used blk_dflush() to guarantee that both headers are updated before jumping into the OS. So in my scenario I need to ensure that those 2 writes will land to the NVMe. I think FUA suggested by Neil in v1 feedback should be a robust solution for NVMe, but I went with a 'flush' solution first. > > --Sean
