Re: [PATCH] bpf: add bpf_real_inode() kfunc

[Christoph Hellwig <hch@infradead.org>]

On Fri, Apr 10, 2026 at 12:42:41AM +0800, Gao Xiang wrote:
> >   - a lot less I/O amplification
> 
> But not quite sure recently how extended OOB data is
> kept within the physical media (I remembered in the
> early years each page of raw nand flashes has
> several-byte OOB together with the user data): if
> it's along with the corresponding LBA main area, I
> guess it has to read extended data among multiple
> LBAs (but the LBA main data may not relate to this
> partcular I/O) in order to verify the hash of the
> hashes.

For HDD it it is stored next to the media, and doesn't introduce
extra seeks.  For NAND-based SSDs it typically is stored close to
the data as well.  NAND pages are significantly larger than the
exposed block size for any modern SSD.

> 
> >   - a sane way to actually have verification (including authenticated
> >     encryption) in a writable file system
> 
> Yet if considering modification, it need to move up
> the tree and recalculate/update all hashes until the
> root hash, it's not a low-overhead task TBH, and need
> to apply to every single on-disk change.

It needs to be applied in-memory for every changed, and persisted to
disk on every fsync or equivalent operation.