On Tue, Aug 06, 2019 at 07:48:00AM -0700, Darrick J. Wong wrote: > On Tue, Aug 06, 2019 at 02:07:24PM +0200, Carlos Maiolino wrote: > > 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? > > I probably would've fixed the truncation behavior in the old code and > based the fiemap-fibmap conversion on that so that anyone who wants to > backport the behavior change to an old kernel has an easier time of it. > Well, another problem in fixing it in the old code, is that bmap() can't properly return errors :P After this patchset, bmap() will be able to return errors, so we can easily fix it, once we won't need to 'guess' what a zero return mean from bmap() > But afterwards probably works just as well since I don't feel like tying > ourselves in more knots over an old interface. ;) > > --D > > > Cheers > > > > > > -- > > Carlos -- Carlos
