commit bd23f5fc2c4fb475afec01280b8c557655ba68ba
author James Sullivan <jfsulliv@fuchsia.infra.roller.google.com> Fri Dec 12 12:17:31 2025 -0800
committer Copybara-Service <copybara-worker@google.com> Fri Dec 12 12:19:09 2025 -0800
tree b42a0b39a66c2de263eb4e6256356aaf1befd37a
parent c08758df1717f8b569fb7e90ccba7717c1c237ef

[roll] Roll fuchsia [block] Rationalize FUA/barriers

There were several issues and inconsistencies with how the PRE_BARRIER
and FORCE_ACCESS write flags were handled in the new block server:
- Barriers were simulated when unavailable, but FUA was not.
- Barriers were handled by stripping the PRE_BARRIER flag and calling
  `async_interface::Interface::barrier` to attach the barrier to the
  next request.  This is not very compatible with barriers for the CQHCI
  driver, where barriers are issued by a flag on a request, rather than
  a separate request.  Arguably this is the more common scenario, and
  avoids confusion around which request the barrier is associated with.
- There was no FUA_SUPPORT bit in fuchsia.hardware.block.Flag.

Fix these issues and rationalize the handling of FUA/barriers as
follows:

- Adds a BARRIER_SUPPORT bit, like FUA_SUPPORT.
- Clarifies the behaviour of PRE_BARRIER in a grouped request.
  It is vastly simpler to implement PRE_BARRIER simulation if we do
  *not* guarantee that a PRE_BARRIER request within a group will be
  sequenced with all other requests in the same group, because the
  entire batch is "in-flight" (only one response is expected by the
  client).  Clients must put PRE_BARRIER requests in a separate group,
  and submit this group after all prior requests they care about have
  been responded to.
- The block server library will simply forward the
  PRE_BARRER/FORCE_ACCESS flag to implementations, unless the
  implementation advertises that it does not support the relevant
  feature.
- If the implementation doesn't support the relevant feature, the
  block_server library will simulate barriers and FUA by a pre- and
  post-flush, respectively.  We rely on the existing ActiveRequest
  mechanism to ensure that these are logically all part of the same
  client request.
- Remove the (now defunct) barrier simulation in sdmmc-block-device.

To test this, I plumbed through the ability to set DeviceFlags on the
ramdisk C++ server.

Original-Fixed: 409872119
Multiply: block_server_integration_component.cm
Multiply: ramdisk-test.cm
Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1439555
Original-Revision: 4dbe935ca2e702046fc2f68dbcfe5589f62cf11d
GitOrigin-RevId: e2a46b9e3128095f4ed45f517d911ccbe7fe31e6
Change-Id: I04770fe54996a06e8f88e36f7eb021385d51cd5d