Re: git: 6d408ac49073 - main - fusefs: add a regression test for a cluster_read bug

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Sun, 26 Oct 2025 17:02:01 UTC 
On Sun, Oct 26, 2025 at 10:53:05AM -0600, Alan Somers wrote:
> On Fri, Oct 24, 2025 at 2:13 AM Konstantin Belousov <kostikbel@gmail.com>
> wrote:
> 
> > On Thu, Oct 23, 2025 at 01:41:05PM +0000, Alan Somers wrote:
> > > The branch main has been updated by asomers:
> > >
> > > URL:
> > https://cgit.FreeBSD.org/src/commit/?id=6d408ac490730614b3ed0ebd3caffcd23f303fb4
> > >
> > > commit 6d408ac490730614b3ed0ebd3caffcd23f303fb4
> > > Author:     Alan Somers <asomers@FreeBSD.org>
> > > AuthorDate: 2025-10-23 13:40:56 +0000
> > > Commit:     Alan Somers <asomers@FreeBSD.org>
> > > CommitDate: 2025-10-23 13:40:56 +0000
> > >
> > >     fusefs: add a regression test for a cluster_read bug
> > >
> > >     VOP_BMAP is purely advisory.  If VOP_BMAP returns an error during
> > >     readahead, cluster_read should still succeed, because the actual data
> > >     was still read just fine.
> > No, VOP_BMAP() is not advisory.  But read-ahead beyond the first buffer is.
> > The BMAP in question is to translate lblk for read-ahead buffer.
> >
> >
> The FUSE_WRITE request _always_ includes the file's nodeid and offset.  So
> unlike, say, UFS, FUSE_BMAP is only used to make decisions about
> clustering, to compute the amount of readahead.  So I suppose I should've
> said that "FUSE_BMAP is purely advisory".  Thanks for the correction.

I would say that the specific instance of the VOP_BMAP() call is
allowed to fail.