Signed-off-by: Stoyan Gaydarov
---
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 b/fs/btrfs/ctree.c
ind
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 r
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
>
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
[0,2^32) ? That eliminates the arbitary constant of 100, and in some case
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
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
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 numb
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
>
> 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 ENO
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
[...]
10 matches
Mail list logo
