On 21.07.20 г. 17:22 ч., Josef Bacik wrote: > v3->v4: > - Rebased onto a recent misc-next, slight fixup because of commenting around the > flush states. > > v2->v3: > - Rebased onto a recent misc-next > > v1->v2: > - Adjusted a comment in may_commit_transaction. > - Fixed one of the intermediate patches to properly update ->reclaim_size. > > We've had two different things in place to reserve data and metadata space, > because generally speaking data is much simpler. However the data reservations > still suffered from the same issues that plagued metadata reservations, you > could get multiple tasks racing in to get reservations. This causes problems > with cases like write/delete loops where we should be able to fill up the fs, > delete everything, and go again. You would sometimes race with a flusher that's > trying to unpin the free space, take it's reservations, and then it would fail. > > Fix this by moving the data reservations under the metadata ticketing > infrastructure. This gets rid of that problem, and simplifies our enospc code > more by consolidating it into a single path. Thanks, > > Josef > I've gone through the series again and it looks good. However, btrfs_alloc_data_chunk_ondemand no longer allocates a data chunk but simply tries to reserve the requested data space. This means this series needs another patch giving it a more becoming name, something like btrfs_(alloc|reserve)_data_space or some such ?
