On Tue, Aug 06, 2019 at 07:38:40AM +0200, Christoph Hellwig wrote: > On Mon, Aug 05, 2019 at 08:12:58AM -0700, Darrick J. Wong wrote: > > > returned. And IIRC, iomap is the only interface now that cares about issuing a > > > warning. > > > > > > I think the *best* we could do here, is to make the new bmap() to issue the same > > > kind of WARN() iomap does, but we can't really change the end result. > > > > I'd rather we break legacy code than corrupt filesystems. > Yes, I have the same feeling, but this patchset does not have the goal to fix the broken api. > This particular patch should keep existing behavior as is, as the intent > is to not change functionality. Throwing in another patch to have saner > error behavior now that we have a saner in-kernel interface that cleary > documents what it is breaking and why on the other hand sounds like a > very good idea. I totally agree here, and to be honest, I think such change should be in a different patchset rather than a new patch in this series. I can do it for sure, but this discussion IMHO should be done not only here in linux-fsdevel, but also in linux-api, which well, I don't think cc'ing this whole patchset there will do any good other than keep the change discussion more complicated than it should be. I'd rather finish the design and implementation of this patchset, and I'll follow-up it, once it's all set, with a new patch to change the truncation behavior, it will make the discussion way easier than mixing up subjects. What you guys think? Cheers -- Carlos
