Am Mo., 14. Jan. 2019 um 17:50 Uhr schrieb Christoph Hellwig <hch@xxxxxx>: > On Fri, Dec 07, 2018 at 10:34:29AM +0100, Carlos Maiolino wrote: > > On Thu, Dec 06, 2018 at 07:56:02PM +0100, Andreas Grünbacher wrote: > > > Hi, > > > > > > Am Mi., 5. Dez. 2018 um 10:18 Uhr schrieb Carlos Maiolino > > > <cmaiolino@xxxxxxxxxx>: > > > > This is the second version of the complete series with the goal to remove ->bmap > > > > interface completely, in lieu of FIEMAP. > > > > > > I'm not thrilled by this approach. How about exposing the iomap > > > operations at the vfs layer (for example, in the super block) and > > > implementing bmap on top of that instead? > > > > > > > Well, the idea is exactly to get rid of bmap, not reimplement it. We can use the > > same operation for both cases (fiemap+fibmap), so I honestly don't see which > > advantages would be by reimplementing it. > > Exactly. iomap really is a possibly implementation. Everytime we > exposed implementation details at the ops level that created horrible > abuses. The most important still relevant example is > write_begin/write_end, which require fs specific locking but are > exposed in a way where we can't easily enforce that. Yes, locking. The fiemap_fill_cb callback hack still makes the fiemap interface much uglier though. So couldn't the existing iop be used to fill a kernel buffer in a way similar to what functions like kernel_readv do? That would at least avoid wrecking an existing interface. Thanks, Andreas
