From: Tomasz Chmielewski <mangoo@wpkg.org>
To: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: 4.13: No space left with plenty of free space (/home/kernel/COD/linux/fs/btrfs/extent-tree.c:6989 __btrfs_free_extent.isra.62+0xc2c/0xdb0)
Date: Fri, 08 Sep 2017 21:45:51 +0900 [thread overview]
Message-ID: <07038afceffac186c98f02572e5a7aac@wpkg.org> (raw)
In-Reply-To: <409e33c45cf1defe5c582381f00fa562@wpkg.org>
> So the numbers that matter are:
>
>> Data,single: Size:12.84TiB, Used:7.13TiB
>> /dev/md2 12.84TiB
>> Metadata,DUP: Size:79.00GiB, Used:77.87GiB
>> /dev/md2 158.00GiB
>> Unallocated:
>> /dev/md2 3.31TiB
> * If you are using the 'space_cache' it has a known issue:
> https://btrfs.wiki.kernel.org/index.php/Gotchas#Free_space_cache
# mount | grep btrfs
/dev/md2 on /data type btrfs
(rw,noatime,compress-force=zlib,space_cache,subvolid=5,subvol=/)
Citing from the URL you pasted:
Free space cache
Currently sometimes the free space cache v1 and v2 lose track of
free space and a volume can be reported as not having free space when it
obviously does.
Fix: disable use of the free space cache with mount option
nospace_cache.
Fix: remount the volume with -o remount,clear_cache.
Switch to to new free space tree.
What does "switch to to new free space tree" mean / how to do it?
> I also notice that your volume's data free space seems to be
> extremely fragmented, as the large difference here shows
> "Data,single: Size:12.84TiB, Used:7.13TiB".
Yes, it's possible it will be very fragmented: lots of rsync + inplace
and many snapshots. Also - not sure if it matters - IO load is 100% or
close for most of the day.
> Which may mean that it is mounted with 'ssd' and/or has gone a
> long time without a 'balance', and conceivably this can make it
> easier for the free space cache to fail finding space (some
> handwaving here).
It's using HDDs, not mounted with "ssd" option.
I think there wasn't ever a balance run there. Since full balance may
take a few months to finish (!) and causes even more IO, I'm not a big
fan of running it.
Still, it does seem like a bug to me to error with "no space left", when
there is a lot of space left?
Tomasz Chmielewski
https://lxadm.com
next prev parent reply other threads:[~2017-09-08 12:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-08 4:33 4.13: No space left with plenty of free space (/home/kernel/COD/linux/fs/btrfs/extent-tree.c:6989 __btrfs_free_extent.isra.62+0xc2c/0xdb0) Tomasz Chmielewski
2017-09-08 4:56 ` Tomasz Chmielewski
2017-09-08 12:45 ` Tomasz Chmielewski [this message]
2017-09-08 11:02 ` Peter Grandi
2017-09-08 19:57 ` Josef Bacik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=07038afceffac186c98f02572e5a7aac@wpkg.org \
--to=mangoo@wpkg.org \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).