On Mon, Mar 17, 2025 at 02:13:14PM -0700, Bart Van Assche wrote: > On 3/17/25 1:39 PM, Keith Busch wrote: > > On Mon, Mar 17, 2025 at 03:40:10PM -0400, Kent Overstreet wrote: > > > If, OTOH, this is just something that hasn't come up before - the > > > language in the spec is already there, so once code is out there with > > > enough users and a demonstrated use case then it might be a pretty > > > simple nudge - "shoot down this range of the cache, don't just flush it" > > > is a pretty simple code change, as far as these things go. > > > > So you're telling me you've never written SSD firmware then waited for > > the manufacturer to release it to your users? Yes, I jest, and maybe > > YMMV; but relying on that process is putting your destiny in the wrong > > hands. > > As far as I know in the Linux kernel we only support storage device behavior > that has been standardized and also workarounds for bugs. I'm > not sure we should support behavior in the Linux kernel that deviates > from existing standards and that also deviates from longstanding and > well-established conventions. What bcachefs is doing is entirely in line with the behaviour the standard states. Keith and Martin are describing systems with a different interpretation, because they want the side effect (flush cache) without the main effect (possibly evict cache, but read comes from media). It's an amusing state of affairs, but it'd be easily resolved with an admin level NVME command to flip a state bit (like the read recovery level we were also talking about), and anyways multihoming capable NVME devices are an entirely different market from the conventional stuff.
