On Tue, 26 Mar 2013 15:34:06 -0400 Josef Bacik <jbacik@xxxxxxxxxxxx> wrote: > A user reported a problem where he was getting early ENOSPC with hundreds of > gigs of free data space and 6 gigs of free metadata space. This is because the > global block reserve was taking up the entire free metadata space. This is > ridiculous, we have infrastructure in place to throttle if we start using too > much of the global reserve, so instead of letting it get this huge just limit it > to 512mb so that users can still get work done. This allowed the user to > complete his rsync without issues. Thanks Just a note, I added this to 3.7.10 and was able to complete a balance on a "difficult" filesystem (60GB in size, used for /home, with creation and deletion of snapshots by cron), that was otherwise seeming to loop/hang and continuously spewing -28 errors into dmesg. > Cc: stable@xxxxxxxxxxxxxxx > Reported-and-tested-by: Stefan Priebe <s.priebe@xxxxxxxxxxxx> > Signed-off-by: Josef Bacik <jbacik@xxxxxxxxxxxx> > --- > fs/btrfs/extent-tree.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c > index c08c7c8..5791da2 100644 > --- a/fs/btrfs/extent-tree.c > +++ b/fs/btrfs/extent-tree.c > @@ -4554,7 +4554,7 @@ static void update_global_block_rsv(struct btrfs_fs_info *fs_info) > spin_lock(&sinfo->lock); > spin_lock(&block_rsv->lock); > > - block_rsv->size = num_bytes; > + block_rsv->size = min_t(u64, num_bytes, 512 * 1024 * 1024); > > num_bytes = sinfo->bytes_used + sinfo->bytes_pinned + > sinfo->bytes_reserved + sinfo->bytes_readonly + -- With respect, Roman
Attachment:
signature.asc
Description: PGP signature
