Luis Chamberlain <mcgrof@xxxxxxxxxx> writes: > One of the recurring themes that comes up at LSF is "iomap has little > to no documentation, it is hard to use". I've only recently taken a > little nose dive into it, and so I also can frankly admit to say I don't > grok it well either yet. However, the *general* motivation and value is clear: > avoiding the old ugly monster of struct buffer_head, and abstracting > the page cache for non network filesystems, and that is because for > network filesystems my understanding is that we have another side effort > for that. We could go a bit down memory lane on prior attempts to kill > the struct buffer_head evil demon from Linux, or why its evil, but I'm not > sure if recapping that is useful at this point in time, let me know, I could > do that if it helps if folks want to talk about this at LSF. For now I rather It would certainly help to hear on what are our plans of IOMAP_F_BUFFER_HEAD flag and it's related code. I know it is there for gfs2, but it would be good to know on what are our plans before we start converting all other filesystems to move to iomap? Do we advise on not to use this path for other filesystems? Do we plan to deprecate it in order to kill buffer heads in future? e.g. root> git grep "buffer_head" fs/iomap/ fs/iomap/buffered-io.c:#include <linux/buffer_head.h> Wanted more insights on this and our plans w.r.t other filesystem wanting to use it. So a short walk down the memory lane and our plans for future w.r.t IOMAP_F_BUFFER_HEAD would certainly help. Thanks -ritesh
