After an online resize, the filesystem reports its new size, but
still runs out of space at the old size:
Mar 9 08:12:59 vlad kernel: no space left, need 4096, 380928 delalloc bytes,
51509866496 bytes_used, 0 bytes_reserved, 0 bytes_pinned, 0 bytes_readonly, 0
may use51510247424 total
[...]
This is just a hunch, but maybe the handling of spare files (such as
.vdi) is not ideal or not what we're used to with extN. Normally
skipped blocks do not count towards the disk full size, but given
btrfs' nature they may count as a reservation that would certainly
cause an early ENOSPC.
On Mon, Mar 09, 2009 at 07:08:16AM -0600, Yien Zheng wrote:
At this point I'm wondering if this is a anomaly or if it has anything
to do with using an SSD. It seems the pre-2.7.29-rc7 code had a hard
stop at 85%. But the recent patch doesn't seem to have solve the
issue for me. Is there
Lee Trager wrote:
Sorry it took so long to reply its been a crazy week for me.
You're lucky it was only a week, I often have crazy months!
I can't believe I made such a stupid mistake.
Back when I started in computers, I thought 16 bits would
be more than I would ever need to count the
søn, 08 03 2009 kl. 20:03 -0600, skrev Yien Zheng:
Thanks Jens! My research had indicated something about 64-bit
division and using do_div, but you cleared it up for me.
The fragmentation_percent function ultimately does another divide to
get the percentage, so here's what I did to get the
On Mon, Mar 09, 2009 at 10:31:41AM +, Hugo Mills wrote:
After an online resize, the filesystem reports its new size, but
still runs out of space at the old size:
[...]
Unmounting and remounting the filesystem seems to make the new
space available for use again.
This is the
On Mon, Mar 09, 2009 at 03:21:06PM -, Oliver Mattos wrote:
So the idea of the function is to return an integer in the range
[0,100]?
Why are we using a range of 0 to 100 anyway? 100 seems like an arbitary
value for kernel space - why not just keep it as a value in the range
Josef Bacik wrote:
On Mon, Mar 09, 2009 at 03:21:06PM -, Oliver Mattos wrote:
So the idea of the function is to return an integer in the range
[0,100]?
Why are we using a range of 0 to 100 anyway? 100 seems like an arbitary
value for kernel space - why not just keep it as a value in the
Signed-off-by: Stoyan Gaydarov stoyboy...@gmail.com
---
fs/btrfs/ctree.c|3 +--
fs/btrfs/extent-tree.c |3 +--
fs/btrfs/free-space-cache.c |3 +--
fs/btrfs/tree-log.c |3 +--
4 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/ctree.c
