Jeff Moyer wrote: > Dan Williams <dan.j.willi...@intel.com> writes: > > > Keith Busch wrote: > >> On Wed, Nov 13, 2024 at 01:03:58PM -0600, Ira Weiny wrote: > >> > Keith Busch wrote: > >> > > From: Keith Busch <kbu...@kernel.org> > >> > > > >> > > bip is NULL before bio_integrity_prep(). > >> > > >> > Did this fail in some way the user might see? How was this found? > >> > >> I think this means no one ever used block integrity with btt. :) > >> > >> I found this purely from code inspection because I was combing through > >> bio_integrity for a completely unrelated problem. I was trying to make > >> sense of how other drivers use it, and this one didn't make any. > >> > >> > I think the code is correct but should this be backported to stable or > >> > anything? > >> > >> Up to you! It's not fixing a regression since it appears to have never > >> worked before. You can also just delete support for it entirely if no > >> one cares to use this feature. > > > > I think most people are just hoping that filesystem metadata checksums > > are catching torn writes and not using btt. For the few that do not have > > a checksumming filesystem and are using btt I only expect they are using > > 512 or 4K sector sizes and not the sizes with integrity metadata. For > > the ones that are using the odd sizes with integrity metadata they > > obviously do not care about the integrity data being transferred since > > that never apparently worked. > > > > My vote is delete the integrity support, but keep the odd sector size > > support for compatibility. > > More generally, does anyone use btt? Should we start the deprecation > process for it?
True, I think it is worth starting the deprecation process and see who screams. It is easy enough to revive if there are still users out there that have not since moved back to NVME for storage.
