On Thu, Jun 22, 2017 at 09:51:47AM -0400, [email protected] wrote: > From: Jeff Mahoney <[email protected]> > > In a heavy write scenario, we can end up with a large number of pinned bytes. > This can translate into (very) premature ENOSPC because pinned bytes > must be accounted for when allowing a reservation but aren't accounted for > when deciding whether to create a new chunk. > > This patch adds the accounting to should_alloc_chunk so that we can > create the chunk.
Hey, Jeff, Does this fix your ENOSPC problem on a fresh filesystem? I just tracked down an ENOSPC issue someone here reported when doing a btrfs send to a fresh filesystem and it sounds a lot like your issue: metadata bytes_may_use shoots up but we don't allocate any chunks for it. I'm not seeing how including bytes_pinned will help for this case. We won't have any pinned bytes when populating a new fs, right? I don't have a good solution. Allocating chunks based on bytes_may_use is going to way over-allocate because of our worst-case estimations. I'm double-checking now that the flusher is doing the right thing and not missing anything. I'll keep digging, just wanted to know if you had any thoughts. > Signed-off-by: Jeff Mahoney <[email protected]> > --- > fs/btrfs/extent-tree.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c > index 33d979e9ea2a..88b04742beea 100644 > --- a/fs/btrfs/extent-tree.c > +++ b/fs/btrfs/extent-tree.c > @@ -4377,7 +4377,7 @@ static int should_alloc_chunk(struct btrfs_fs_info > *fs_info, > { > struct btrfs_block_rsv *global_rsv = &fs_info->global_block_rsv; > u64 num_bytes = sinfo->total_bytes - sinfo->bytes_readonly; > - u64 num_allocated = sinfo->bytes_used + sinfo->bytes_reserved; > + u64 num_allocated = sinfo->bytes_used + sinfo->bytes_reserved + > sinfo->bytes_pinned; > u64 thresh; > > if (force == CHUNK_ALLOC_FORCE) > -- > 2.11.0 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
