On Wed, 29 Jan 2025 at 20:04, Goffredo Baroncelli <kreijack@xxxxxxxxx> wrote: > > On 29/01/2025 15.02, Kanchan Joshi wrote: > > TL;DR first: this makes Btrfs chuck its checksum tree and leverage NVMe > > SSD for data checksumming. > > > > Now, the longer version for why/how. > > > > End-to-end data protection (E2EDP)-capable drives require the transfer > > of integrity metadata (PI). > > This is currently handled by the block layer, without filesystem > > involvement/awareness. > > The block layer attaches the metadata buffer, generates the checksum > > (and reftag) for write I/O, and verifies it during read I/O. > > > May be this is a stupid question, but if we can (will) avoid storing the checksum > in the FS, which is the advantage of having a COW filesystem ? I was wondering the same. My understanding is the checksums are there primarily to protect against untrusted devices or data transfers over the line. And now suddenly we're going to trust them? What's even the point then? Is there any other advantage of having these checksums that I may be missing? Perhaps logic code bugs accidentally corrupting the data? Is the stored payload even ever touched? That would not be wanted, right? Or perhaps data mangled on the storage by an attacker? > My understand is that a COW filesystem is needed mainly to synchronize > csum and data. Am I wrong ? > > [...] > > BR > > -- > gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> > Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 >
