On Sat, Mar 15, 2025 at 11:43:30AM -0600, Jens Axboe wrote: > On 3/15/25 11:27 AM, Kent Overstreet wrote: > > On Sat, Mar 15, 2025 at 11:03:20AM -0600, Jens Axboe wrote: > >> On 3/15/25 11:01 AM, Kent Overstreet wrote: > >>> On Sat, Mar 15, 2025 at 10:47:09AM -0600, Jens Axboe wrote: > >>>> On 3/11/25 2:15 PM, Kent Overstreet wrote: > >>>>> REQ_FUA|REQ_READ means "do a read that bypasses the controller cache", > >>>>> the same as writes. > >>>>> > >>>>> This is useful for when the filesystem gets a checksum error, it's > >>>>> possible that a bit was flipped in the controller cache, and when we > >>>>> retry we want to retry the entire IO, not just from cache. > >>>>> > >>>>> The nvme driver already passes through REQ_FUA for reads, not just > >>>>> writes, so disabling the warning is sufficient to start using it, and > >>>>> bcachefs is implementing additional retries for checksum errors so can > >>>>> immediately use it. > >>>> > >>>> This one got effectively nak'ed by various folks here: > >>>> > >>>>> Link: https://lore.kernel.org/linux-block/20250311133517.3095878-1-kent.overstreet@xxxxxxxxx/ > >>>> > >>>> yet it's part of this series and in linux-next? Hmm? > >>> > >>> As I explained in that thread, they were only thinking about the caching > >>> of writes. > >>> > >>> That's not what we're concerned about; when we retry a read due to a > >>> checksum error we do not want the previous _read_ cached. > >> > >> Please follow the usual procedure of getting the patch acked/reviewed on > >> the block list, and go through the usual trees. Until that happens, this > >> patch should not be in your tree, not should it be staged in linux-next. > > > > It's been posted to linux-block and sent to your inbox. If you're going > > to take it that's fine, otherwise - since this is necessary for handling > > bitrotted data correctly and I've got users who've been waiting on this > > patch series, and it's just deleting a warning, I'm inclined to just > > send it. > > > > I'll make sure he's got the lore links and knows what's going on, but > > this isn't a great thing to be delaying on citing process. > > Kent, you know how this works, there's nothing to argue about here. > > Let the block people get it reviewed and staged. You can't just post a > patch, ignore most replies, and then go on to stage it yourself later > that day. It didn't work well in other subsystems, and it won't work > well here either. Jens, those replies weren't ignored, the concerns were answered. Never have I seen that considered "effectively nacked". And as far as "how things work around here" - let's not even go there, lest we have to cover your issues with process.
