From: dmukhin@ford.com
To: Sean Anderson <seanga2@gmail.com>
Cc: dmukhin@ford.com, u-boot@lists.denx.de,
neil.armstrong@linaro.org, sjg@chromium.org, trini@konsulko.com
Subject: Re: [PATCH v2 4/6] cmd: Add flush support for all blk devices
Date: Thu, 4 Jun 2026 20:53:53 -0700 [thread overview]
Message-ID: <aiJIUajDdCz3tnkc@kraken> (raw)
In-Reply-To: <757cf33e-0a87-45d1-29f5-aac6fd5282c3@gmail.com>
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, dmukhin@ford.com wrote:
> > From: Denis Mukhin <dmukhin@ford.com>
> >
> > 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
next prev parent reply other threads:[~2026-06-05 3:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-29 3:44 [PATCH v2 0/6] nvme: few fixups dmukhin
2026-05-29 3:44 ` [PATCH v2 1/6] drivers: nvme: Log I/O timeouts dmukhin
2026-05-29 9:56 ` Simon Glass
2026-05-29 3:44 ` [PATCH v2 2/6] drivers: block: Introduce blk_flush()/blk_dflush() dmukhin
2026-05-29 9:57 ` Simon Glass
2026-05-29 3:44 ` [PATCH v2 3/6] drivers: nvme: Implement flush command dmukhin
2026-05-29 9:57 ` Simon Glass
2026-05-29 3:44 ` [PATCH v2 4/6] cmd: Add flush support for all blk devices dmukhin
2026-05-29 9:57 ` Simon Glass
2026-06-05 3:55 ` dmukhin
2026-06-03 17:43 ` Sean Anderson
2026-06-04 17:01 ` Simon Glass
2026-06-05 3:53 ` dmukhin [this message]
2026-05-29 3:44 ` [PATCH v2 5/6] drivers: nvme: Export nvme_shutdown() dmukhin
2026-05-29 9:57 ` Simon Glass
2026-05-29 3:44 ` [PATCH v2 6/6] docs: nvme: Update QEMU command for testing dmukhin
2026-05-29 9:58 ` Simon Glass
2026-05-29 9:58 ` [v2,0/6] nvme: few fixups Simon Glass
2026-06-03 16:22 ` (subset) [PATCH v2 0/6] " Neil Armstrong
2026-06-04 6:32 ` neil.armstrong
2026-06-05 3:59 ` dmukhin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aiJIUajDdCz3tnkc@kraken \
--to=dmukhin@ford.com \
--cc=neil.armstrong@linaro.org \
--cc=seanga2@gmail.com \
--cc=sjg@chromium.org \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.