On Sun, Oct 26, 2025 at 10:53:05AM -0600, Alan Somers wrote: > On Fri, Oct 24, 2025 at 2:13 AM Konstantin Belousov <[email protected]> > 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 <[email protected]> > > > AuthorDate: 2025-10-23 13:40:56 +0000 > > > Commit: Alan Somers <[email protected]> > > > 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.
