Re: [PATCH 00/21] Lock extents before pages

[Goldwyn Rodrigues <rgoldwyn@suse.de>]

On 23:50 09/03, Christoph Hellwig wrote:
> On Thu, Mar 09, 2023 at 07:10:51PM +0100, David Sterba wrote:
> > I've picked the branch from your git repository (applies on top of
> > misc-next) and will add it to for-next. We may need to keep it there for
> > some time, with this kind of core change it's not possible to do reverts
> > in case we find serious problems.
> 
> I am really worried about the i_count hack.  It is fundamentlly wrong
> and breaks inode lifetime rules.  Furthermore there is no attempt
> at understanding why it happens (or even if it is new with this series).

So this (another version) patch which first added working with i_count is:
8180ef8894fa ("Btrfs: keep inode pinned when compressing writes")

For async, inode is still referenced until all the pages
are written back and cleared in end_compressed_writeback().
evict() waits for all writeback to be completed. Josef, is this
correct?

I removed the ihold() and delayed iput sequence and shifted
unlock_extent() immediately after submit_compressed_extents(). It is
working fine with no crashes for compress tests. But since this is a
race condition I need to be sure if it is the correct thing to do. I
have updated the git [1] but it needs more testing.

In any case, there is another issue with scrubbing which I need to
resolve: btrfs/06[0-3]. I am on vacation next week and the earliest I
can get back to it is March 20.


> 
> > 
> > Optimistic plan is to get it stabilized during current dev cycle and
> > then one more cycle for stabilization once it's in the master branch.
> 
> It is going to clash with quite a bit of other work going in this area
> I fear.

[1] https://github.com/goldwynr/linux/tree/lock-rearrange

-- 
Goldwyn