On 3.12.18 г. 17:24 ч., Josef Bacik wrote:
> For FLUSH_LIMIT flushers (think evict, truncate) we can deadlock when
> running delalloc because we may be holding a tree lock. We can also
> deadlock with delayed refs rsv's that are running via the committing
> mechanism. The only safe operations
On Mon, Dec 03, 2018 at 10:24:58AM -0500, Josef Bacik wrote:
> For FLUSH_LIMIT flushers (think evict, truncate) we can deadlock when
> running delalloc because we may be holding a tree lock. We can also
> deadlock with delayed refs rsv's that are running via the committing
> mechanism. The only s
For FLUSH_LIMIT flushers (think evict, truncate) we can deadlock when
running delalloc because we may be holding a tree lock. We can also
deadlock with delayed refs rsv's that are running via the committing
mechanism. The only safe operations for FLUSH_LIMIT is to run the
delayed operations and t
On 26.11.18 г. 14:41 ч., Nikolay Borisov wrote:
>
>
> On 21.11.18 г. 21:03 ч., Josef Bacik wrote:
>> For FLUSH_LIMIT flushers we really can only allocate chunks and flush
>> delayed inode items, everything else is problematic. I added a bunch of
>> new states and it lead to weirdness in the F
On 21.11.18 г. 21:03 ч., Josef Bacik wrote:
> For FLUSH_LIMIT flushers we really can only allocate chunks and flush
> delayed inode items, everything else is problematic. I added a bunch of
> new states and it lead to weirdness in the FLUSH_LIMIT case because I
> forgot about how it worked. So
For FLUSH_LIMIT flushers we really can only allocate chunks and flush
delayed inode items, everything else is problematic. I added a bunch of
new states and it lead to weirdness in the FLUSH_LIMIT case because I
forgot about how it worked. So instead explicitly declare the states
that are ok for
