On Wed, Sep 03, 2025 at 05:19:04PM +0200, Mateusz Guzik wrote: > On Wed, Sep 3, 2025 at 5:16 PM Mateusz Guzik <mjguzik@xxxxxxxxx> wrote: > > On Wed, Sep 3, 2025 at 4:03 PM Mark Tinguely <mark.tinguely@xxxxxxxxxx> wrote: > > For now that would indeed work in the sense of providing the expected > > behavior, but there is the obvious mismatch of the filesystem claiming > > the inode should not be dropped (by returning 0) and but using a side > > indicator to drop it anyway. This looks like a split-brain scenario > > and sooner or later someone is going to complain about it when they do > > other work in iput_final(). If I was maintaining the layer I would > > reject the idea, but if the actual gatekeepers are fine with it... > > > > The absolute best thing to do long run is to move the i/o in > > ->evict_inode, but someone familiar with the APIs here would do the > > needful(tm) and that's not me. > > I mean the best thing to do in the long run is to move the the write > to ->evict_inode, but I don't know how to do it and don't have any > means to test ocfs2 anyway. Hopefully the ocfs2 folk will be willing > to sort this out? gfs2 calls write_inode_now() from ->evict_inode, so it is definitely possible to do this. However, given that ocfs2 is largely a legacy filesystem these days, I suspect that you are going to have to do this conversion yourself if you want this approach to progress in a timely manner. :/ -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
